# A Bayesian Approach to Duplicate Detection for Real Estate Listings

Felipe Dioguardi¹, Leandro Antonelli¹, Marcos May³, Juan Pablo del Río³, and Diego Torres¹,²

¹ LIFIA, CICPBA-Facultad de Informática, UNLP, Argentina
{name.surname}@lifia.info.unlp.edu.ar

Departamento de Ciencia y Tecnología, UNQ, Argentina

³ LINTA-CICPBA, FaHCE, UNLP, Argentina

⁴ CONICET, Argentina

**Abstract.** The availability of large amounts of real estate data on the internet presents a great opportunity for analysts and statisticians to derive insights. However, ensuring the quality of the data can be challenging due to the presence of duplicate listings. This study proposes a duplicate detection strategy for a real estate knowledge graph containing listings scraped from different web pages. The presented approach involves using Duke to discover the implicit owl: sameAs links between records, which achieved a precision of 66.8%, a recall of 70.4%, and an F-measure of 68.6%. Although many strategies are based on using a single metric function to compare records, it was found that segmenting this comparison according to the attributes compared and giving each segment a different weight on the matching result is a successful method for solving this problem. The strategy was evaluated through a ground truth dataset created by domain experts, which consisted of a real estate list-ing knowledge graph with duplicate and unique entities. This approach effectively cleaned the knowledge graph of noisy data and can be useful for making accurate statistical analyses on real estate domains. The suggested approach can be used to create a real estate observatory that analyses real estate listings knowledge from different sources to generate useful statistics. Analysts can use this tool to extract valuable information and make data-driven decisions in the real estate market.

**Keywords:** Duplicate detection · Knowledge base · Real estate listings

## 1 Introduction

The sheer volume of online information poses advantages and disadvantages when extracting insights from it. While more data can provide new ways of measuring and understanding the domain, poor-quality data can lead to inaccurate conclusions and bad decision-making [3]. Therefore, prioritizing data quality over quantity is crucial when managing a large knowledge base. For this reason, duplicate detection is a key task during the preprocessing stage of information.

Over the years, many researchers have proposed strategies to detect duplicaterecords [1,9]. Still, their effectiveness varies depending on factors such as the amount of knowledge, the type of information, and the domain it belongs to. This paper evaluates the performance of a duplicate detection strategy based on a Bayesian Classifier over a real estate listings knowledge base built from recordsextracted from different websites.

Duplicate detection, often called record linkage, entity resolution, and data deduplication, is the process of identifying different records that refer to the same entity [5]. Such a problem is not trivial, as it involves some challenging steps, from the careful selection of record pairs to be compared to the methodof comparison of these records and the final linking process. Removing duplicate records from a knowledge base is critical for ensuring reliable and trustworthy data [10], as their presence can impair statistical analysis and undermine their results.
# A Bayesian Approach to Duplicate Detection for Real Estate Listings

Felipe Dioguardi¹, Leandro Antonelli¹, Marcos May³, Juan Pablo del Río³, and Diego Torres¹,²

¹ LIFIA, CICPBA-Facultad de Informática, UNLP, Argentina
{name.surname}@lifia.info.unlp.edu.ar

Departamento de Ciencia y Tecnología, UNQ, Argentina

³ LINTA-CICPBA, FaHCE, UNLP, Argentina

⁴ CONICET, Argentina

**Abstract.** The availability of large amounts of real estate data on the internet presents a great opportunity for analysts and statisticians to derive insights. However, ensuring the quality of the data can be challenging due to the presence of duplicate listings. This study proposes a duplicate detection strategy for a real estate knowledge graph containing listings scraped from different web pages. The presented approach involves using Duke to discover the implicit owl: sameAs links between records, which achieved a precision of 66.8%, a recall of 70.4%, and an F-measure of 68.6%. Although many strategies are based on using a single metric function to compare records, it was found that segmenting this comparison according to the attributes compared and giving each segment a different weight on the matching result is a successful method for solving this problem. The strategy was evaluated through a ground truth dataset created by domain experts, which consisted of a real estate list-ing knowledge graph with duplicate and unique entities. This approach effectively cleaned the knowledge graph of noisy data and can be useful for making accurate statistical analyses on real estate domains. The suggested approach can be used to create a real estate observatory that analyses real estate listings knowledge from different sources to generate useful statistics. Analysts can use this tool to extract valuable information and make data-driven decisions in the real estate market.

**Keywords:** Duplicate detection · Knowledge base · Real estate listings

## 1 Introduction

The sheer volume of online information poses advantages and disadvantages when extracting insights from it. While more data can provide new ways of measuring and understanding the domain, poor-quality data can lead to inaccurate conclusions and bad decision-making [3]. Therefore, prioritizing data quality over quantity is crucial when managing a large knowledge base. For this reason, duplicate detection is a key task during the preprocessing stage of information.

Over the years, many researchers have proposed strategies to detect duplicaterecords [1,9]. Still, their effectiveness varies depending on factors such as the amount of knowledge, the type of information, and the domain it belongs to. This paper evaluates the performance of a duplicate detection strategy based on a Bayesian Classifier over a real estate listings knowledge base built from recordsextracted from different websites.

Duplicate detection, often called record linkage, entity resolution, and data deduplication, is the process of identifying different records that refer to the same entity [5]. Such a problem is not trivial, as it involves some challenging steps, from the careful selection of record pairs to be compared to the methodof comparison of these records and the final linking process. Removing duplicate records from a knowledge base is critical for ensuring reliable and trustworthy data [10], as their presence can impair statistical analysis and undermine their results.
Numerous tools and strategies have been proposed to address duplicate detection. For instance, vectorization techniques [13] and fuzzy matching [7] have been suggested to identify potential matches. Likewise, both machine learning models [2] and rule-based systems [11] have been explored to compare potentially matching records. Finally, comprehensive frameworks that automate all aspects of instance matching have also been developed [15]. However, the success of these methods heavily relies on their adaptability to the specific characteristics of each domain, and the selection of an appropriate method can be influenced by factors such as the size of the dataset, the data quality, the nature of the matching functions, and the requirements of the application.

Specifically, in real estate listings, the challenges of deduplication intensify further. The real state market involves having the same building appear in multiple listings. This can happen if, for example, more than one real estate agent offers the building, and each of the agents publishes it in separate listings on the same site. The same logic can apply when the agents publish the same build-ing on different sites. Additionally, completely different listings can have similar descriptions due to templates used by real estate agents or websites. The geo- graphic coordinates of the offered properties can also pose challenges, depending on who publishes them and how. On top of that, naming conventions can vary across sources, making it difficult to identify duplicates without a comprehensive approach that considers all relevant attributes of each listing.

This research aims to assess the efficacy of a duplicate detection strategy that leverages Bayes' Theorem to aggregate probabilities, applied to a knowledge base of real estate listings. The performance of this approach is evaluated using the precision, recall, and F-measure metrics, and an unbiased test is ensured by using a knowledge base with a manually curated ground truth dataset.

The remainder of this paper is organized as follows. Section 2 provides an overview of related work in the field of duplicate detection. Section 3 defines the problem of duplicate detection and outlines the challenges specific to real estate listings. Section 4 describes the knowledge graph used in the study, including its sources and characteristics. In Section 5, the paper presents the metrics used to evaluate the effectiveness of our duplicate detection strategy. Section 6 describes in detail the duplicate detection tool used in this study. Section 7 presents the results of the evaluation. Finally, in Section 8 the paper concludes the evaluation and provides insights into the relative strengths and weaknesses of the different approaches while discussing potential areas for future work.

## 2 Related Work

This section provides an overview of the related work in the area of duplicate detection. Several works have surveyed the literature on duplicate detection tools, such as Elmangarmid et al. [5] in the context of databases, Assi et al. [1] with their survey on instance matching systems, and Huaman et al. [9] with their review of the state-of-the-art for duplicate detection in knowledge graphs.

Niu et al. [14] conducted a thorough analysis of the literature on duplicate record detection, covering various techniques, algorithms, and tools used to detect duplicate records in databases. They also discussed common errors that can make duplicate matching difficult and presented methods for improving efficiency and scalability in approximate duplicate detection algorithms. Zong et al. [16] proposed an approach for deduplication that involves extracting semantic information from the material record names and representing it in a form that allows for effective comparisons to be made.

Manku et al. [12] developed a near-duplicate detection system for a multi-billion-page repository, demonstrating the applicability of Charikar's fingerprinting technique for this goal, and evaluating it over real data to confirm the practicality of their design.

Dong et al. [4] studied how to improve truth discovery by detecting dependence between sources and analysing the accuracy of sources. They developed Bayesian models that discover copiers by analysing values shared between sources, and the results of their models can be considered as a probabilistic database, where each object is associated with a probability distribution of various values in the underlying domain. Experimental results showed that their algorithms can significantly improve the accuracy of truth discovery and are scalable when there are numerous data sources.
Numerous tools and strategies have been proposed to address duplicate detection. For instance, vectorization techniques [13] and fuzzy matching [7] have been suggested to identify potential matches. Likewise, both machine learning models [2] and rule-based systems [11] have been explored to compare potentially matching records. Finally, comprehensive frameworks that automate all aspects of instance matching have also been developed [15]. However, the success of these methods heavily relies on their adaptability to the specific characteristics of each domain, and the selection of an appropriate method can be influenced by factors such as the size of the dataset, the data quality, the nature of the matching functions, and the requirements of the application.

Specifically, in real estate listings, the challenges of deduplication intensify further. The real state market involves having the same building appear in multiple listings. This can happen if, for example, more than one real estate agent offers the building, and each of the agents publishes it in separate listings on the same site. The same logic can apply when the agents publish the same build-ing on different sites. Additionally, completely different listings can have similar descriptions due to templates used by real estate agents or websites. The geo- graphic coordinates of the offered properties can also pose challenges, depending on who publishes them and how. On top of that, naming conventions can vary across sources, making it difficult to identify duplicates without a comprehensive approach that considers all relevant attributes of each listing.

This research aims to assess the efficacy of a duplicate detection strategy that leverages Bayes' Theorem to aggregate probabilities, applied to a knowledge base of real estate listings. The performance of this approach is evaluated using the precision, recall, and F-measure metrics, and an unbiased test is ensured by using a knowledge base with a manually curated ground truth dataset.

The remainder of this paper is organized as follows. Section 2 provides an overview of related work in the field of duplicate detection. Section 3 defines the problem of duplicate detection and outlines the challenges specific to real estate listings. Section 4 describes the knowledge graph used in the study, including its sources and characteristics. In Section 5, the paper presents the metrics used to evaluate the effectiveness of our duplicate detection strategy. Section 6 describes in detail the duplicate detection tool used in this study. Section 7 presents the results of the evaluation. Finally, in Section 8 the paper concludes the evaluation and provides insights into the relative strengths and weaknesses of the different approaches while discussing potential areas for future work.

## 2 Related Work

This section provides an overview of the related work in the area of duplicate detection. Several works have surveyed the literature on duplicate detection tools, such as Elmangarmid et al. [5] in the context of databases, Assi et al. [1] with their survey on instance matching systems, and Huaman et al. [9] with their review of the state-of-the-art for duplicate detection in knowledge graphs.

Niu et al. [14] conducted a thorough analysis of the literature on duplicate record detection, covering various techniques, algorithms, and tools used to detect duplicate records in databases. They also discussed common errors that can make duplicate matching difficult and presented methods for improving efficiency and scalability in approximate duplicate detection algorithms. Zong et al. [16] proposed an approach for deduplication that involves extracting semantic information from the material record names and representing it in a form that allows for effective comparisons to be made.

Manku et al. [12] developed a near-duplicate detection system for a multi-billion-page repository, demonstrating the applicability of Charikar's fingerprinting technique for this goal, and evaluating it over real data to confirm the practicality of their design.

Dong et al. [4] studied how to improve truth discovery by detecting dependence between sources and analysing the accuracy of sources. They developed Bayesian models that discover copiers by analysing values shared between sources, and the results of their models can be considered as a probabilistic database, where each object is associated with a probability distribution of various values in the underlying domain. Experimental results showed that their algorithms can significantly improve the accuracy of truth discovery and are scalable when there are numerous data sources.
### 3 Problem Definition

This section will explore the problem of detecting duplicates in knowledge graphs, examining its complexity and the common structure of potential solutions. Firstly, essential concepts related to knowledge representation and the definition of du- plicates will be introduced.

A knowledge base is a collection of concepts related to a specific domain that can be stored in various formats, such as XML or RDF. These formats allow for the creation of a knowledge graph, which represents knowledge as a network of entities linked by relations, capturing their semantic relationships and enabling the discovery of new knowledge through implicit connections. Ontologies are a key component of knowledge bases, providing a formal and structured way of representing concepts and their relationships within a domain. They define the vocabulary and rules for describing entities and their relationships, allowing for interoperability between different knowledge bases and the sharing of knowledge across domains.

Duplicates in knowledge graphs occur when two nodes representing the same entity have different identifiers. Nodes that share the same attributes but differ in their identifiers are called exact duplicates. On the other hand, nodes that differ in some or all of their attributes but still refer to the same entity, are called near-exact or fuzzy duplicates. For example, consider the two nodes shown in Figure 1. Despite having identical attributes (e.g., title, location, price), they have different identifiers. Similarly, in Figure 2, the nodes show some attribute differences (e.g., title, price), but still refer to the same real estate. To capture this fact, it is important to establish an owl: sameAs relationship between these nodes as well, indicating they both represent the same entity. All these duplicates should be linked through the owl: sameAs relationship to indicate that they describe the same entity, forming the basis for detecting duplicates in knowledge graphs.

<figure><img src="image_35.png" /><figcaption>**Fig. 1.** *Exact duplicates in a knowledge graph.*</figcaption></figure>

The problem of duplicate detection has different names depending on the context, such as record matching, record linkage, deduplication, entity resolution, and instance matching. Instance matching (IM) aims to discover duplicated entities between two knowledge graphs. Assi et. al [1] defined it as follows:
### 3 Problem Definition

This section will explore the problem of detecting duplicates in knowledge graphs, examining its complexity and the common structure of potential solutions. Firstly, essential concepts related to knowledge representation and the definition of du- plicates will be introduced.

A knowledge base is a collection of concepts related to a specific domain that can be stored in various formats, such as XML or RDF. These formats allow for the creation of a knowledge graph, which represents knowledge as a network of entities linked by relations, capturing their semantic relationships and enabling the discovery of new knowledge through implicit connections. Ontologies are a key component of knowledge bases, providing a formal and structured way of representing concepts and their relationships within a domain. They define the vocabulary and rules for describing entities and their relationships, allowing for interoperability between different knowledge bases and the sharing of knowledge across domains.

Duplicates in knowledge graphs occur when two nodes representing the same entity have different identifiers. Nodes that share the same attributes but differ in their identifiers are called exact duplicates. On the other hand, nodes that differ in some or all of their attributes but still refer to the same entity, are called near-exact or fuzzy duplicates. For example, consider the two nodes shown in Figure 1. Despite having identical attributes (e.g., title, location, price), they have different identifiers. Similarly, in Figure 2, the nodes show some attribute differences (e.g., title, price), but still refer to the same real estate. To capture this fact, it is important to establish an owl: sameAs relationship between these nodes as well, indicating they both represent the same entity. All these duplicates should be linked through the owl: sameAs relationship to indicate that they describe the same entity, forming the basis for detecting duplicates in knowledge graphs.

<figure><img src="image_49.png" /><figcaption>**Fig. 1.** *Exact duplicates in a knowledge graph.*</figcaption></figure>

The problem of duplicate detection has different names depending on the context, such as record matching, record linkage, deduplication, entity resolution, and instance matching. Instance matching (IM) aims to discover duplicated entities between two knowledge graphs. Assi et. al [1] defined it as follows:
<figure><img src="image_36.png" /><figcaption>Fig. 2. Fuzzy duplicates in a knowledge graph.</figcaption></figure>

**Definition 1 (Instance matching).** Given two sets of instances S and T belonging to two KBs ($KB_1$ and $KB_2$), the aim of IM is to discover the set M of identity links owl: sameAs, according to a chosen identity criterion, which are not already defined in the KBs. Formally, $M = \{(i_1, i_2) | (i_1, i_2) \in S \times T, \langle i_1, \text{owl: sameAs}, i_2 \rangle, \langle i_1, \text{owl: sameAs}, i_2 \rangle \notin KB_1 \cup KB_2\}$.

To detect duplicates within a knowledge graph, duplicate detection can be defined as an instance matching problem where the graph is compared to itself, i.e., where $KG_1 = KG_2$.

Detecting duplicates in knowledge graphs is complex and depends on the size of the graph and the nature of the duplicates. Detecting duplicates efficiently involves four steps: preprocessing, blocking, matching, and clustering. Preprocessing cleans and normalizes the data to remove syntactical and formatting differences. Blocking divides the data into smaller subsets to reduce the search space. Matching compares the attributes of candidate duplicates and determines whether they refer to the same entity. Clustering groups together duplicates that refer to the same entity.

Detecting and resolving duplicates is crucial to ensure trustworthy and reliable data in knowledge graphs. By improving the accuracy and effectiveness of duplicate detection in knowledge graphs, more informed decisions can be made and better outcomes can be achieved.

# 4 Knowledge Graph

This section will discuss the knowledge graph used in the context of the duplicatedetection system for real estate listings.

The knowledge graph is a critical component of the duplicate detection sys-tem, as it stores and organizes real estate listings from various sources and captures the semantic relationships between them. The real estate listings in the knowledge graph come from different websites and agents, resulting in a high level of heterogeneity in the information. This heterogeneity can make it chal-lenging to detect duplicates due to the differences in data format and structure.
<figure><img src="image_50.png" /><figcaption>Fig. 2. Fuzzy duplicates in a knowledge graph.</figcaption></figure>

**Definition 1 (Instance matching).** Given two sets of instances S and T belonging to two KBs ($KB_1$ and $KB_2$), the aim of IM is to discover the set M of identity links owl: sameAs, according to a chosen identity criterion, which are not already defined in the KBs. Formally, $M = \{(i_1, i_2) | (i_1, i_2) \in S \times T, \langle i_1, \text{owl: sameAs}, i_2 \rangle, \langle i_1, \text{owl: sameAs}, i_2 \rangle \notin KB_1 \cup KB_2\}$.

To detect duplicates within a knowledge graph, duplicate detection can be defined as an instance matching problem where the graph is compared to itself, i.e., where $KG_1 = KG_2$.

Detecting duplicates in knowledge graphs is complex and depends on the size of the graph and the nature of the duplicates. Detecting duplicates efficiently involves four steps: preprocessing, blocking, matching, and clustering. Preprocessing cleans and normalizes the data to remove syntactical and formatting differences. Blocking divides the data into smaller subsets to reduce the search space. Matching compares the attributes of candidate duplicates and determines whether they refer to the same entity. Clustering groups together duplicates that refer to the same entity.

Detecting and resolving duplicates is crucial to ensure trustworthy and reliable data in knowledge graphs. By improving the accuracy and effectiveness of duplicate detection in knowledge graphs, more informed decisions can be made and better outcomes can be achieved.

# 4 Knowledge Graph

This section will discuss the knowledge graph used in the context of the duplicatedetection system for real estate listings.

The knowledge graph is a critical component of the duplicate detection sys-tem, as it stores and organizes real estate listings from various sources and captures the semantic relationships between them. The real estate listings in the knowledge graph come from different websites and agents, resulting in a high level of heterogeneity in the information. This heterogeneity can make it chal-lenging to detect duplicates due to the differences in data format and structure.
The knowledge base is stored in two different formats, CSV and RDF. CSV is a simple tabular format that is easy to work with, while RDF is a more complex graph-based format that allows for semantic relationships to be captured. The choice of format depends on the specific requirements of the duplicate detection strategy being evaluated.

The schema defines the variables used in the CSV and ensures that all listings have a consistent set of attributes. Additionally, an ontology is used to create the RDF graph and define relationships between the entities in the knowledge graph. The ontology is derived from established vocabularies and ontologies, such as GoodRelations<fnref n="1" />, Schema.org<fnref n="2" />, FOAF<fnref n="3" />, and RealEstateCore<fnref n="4" /> [8]. These resources provide a rich set of definitions and relationships leveraged to develop the knowledge graph. Specifically, entities such as RealEstateListing, RealEstate, and Agent are defined within the ontology, along with their corresponding relationships.

The attributes for the real estate listings include price, location, number of bedrooms, and square meters. These variables are standardized across all listings to facilitate comparison and detection of duplicates. The ontology, on the other hand, defines the relationships between entities in the graph, such as the relationship between a property and its location or between a property and its agent.

The knowledge graph example depicted in Figure 3 provides an illustration of how the ontology can be effectively used to capture the semantic relationships between different entities in real estate listings. For example, the graph demonstrates how a particular real estate listing can be associated with a specific real estate agency, such as John's Real Estate Agency. Additionally, the listing can have a relationship with its address, which is represented by the Feature entity. If two listings are advertising real estate located at the same address, they would both share a relationship with that instance. By effectively capturing and representing these semantic relationships, the knowledge graph plays a critical role in identifying potential duplicates by comparing not only the attributes of the listings themselves but also the context in which they exist.

<figure><img src="image_37.png" /><figcaption>**Fig. 3.** Example knowledge graph featuring a real estate listing.</figcaption></figure>

<footnote n="1">¹ GoodRelations: http://purl.org/goodrelations/</footnote>

<footnote n="2">² Schema.org: https://schema.org/</footnote>

<footnote n="3">³ FOAF: http://xmlns.com/foaf/0.1/</footnote>

<footnote n="4">⁴ RealEstateCore: https://realestatecore.io/</footnote>
The knowledge base is stored in two different formats, CSV and RDF. CSV is a simple tabular format that is easy to work with, while RDF is a more complex graph-based format that allows for semantic relationships to be captured. The choice of format depends on the specific requirements of the duplicate detection strategy being evaluated.

The schema defines the variables used in the CSV and ensures that all listings have a consistent set of attributes. Additionally, an ontology is used to create the RDF graph and define relationships between the entities in the knowledge graph. The ontology is derived from established vocabularies and ontologies, such as GoodRelations<fnref n="1" />, Schema.org<fnref n="2" />, FOAF<fnref n="3" />, and RealEstateCore<fnref n="4" /> [8]. These resources provide a rich set of definitions and relationships leveraged to develop the knowledge graph. Specifically, entities such as RealEstateListing, RealEstate, and Agent are defined within the ontology, along with their corresponding relationships.

The attributes for the real estate listings include price, location, number of bedrooms, and square meters. These variables are standardized across all listings to facilitate comparison and detection of duplicates. The ontology, on the other hand, defines the relationships between entities in the graph, such as the relationship between a property and its location or between a property and its agent.

The knowledge graph example depicted in Figure 3 provides an illustration of how the ontology can be effectively used to capture the semantic relationships between different entities in real estate listings. For example, the graph demonstrates how a particular real estate listing can be associated with a specific real estate agency, such as John's Real Estate Agency. Additionally, the listing can have a relationship with its address, which is represented by the Feature entity. If two listings are advertising real estate located at the same address, they would both share a relationship with that instance. By effectively capturing and representing these semantic relationships, the knowledge graph plays a critical role in identifying potential duplicates by comparing not only the attributes of the listings themselves but also the context in which they exist.

<figure><img src="image_51.png" /><figcaption>**Fig. 3.** Example knowledge graph featuring a real estate listing.</figcaption></figure>

<footnote n="1">¹ GoodRelations: http://purl.org/goodrelations/</footnote>

<footnote n="2">² Schema.org: https://schema.org/</footnote>

<footnote n="3">³ FOAF: http://xmlns.com/foaf/0.1/</footnote>

<footnote n="4">⁴ RealEstateCore: https://realestatecore.io/</footnote>
# 5 Metrics

This section defines the metrics used to evaluate the performance of duplicate detection algorithms. It will explain the insights provided by each metric and how they will be calculated.

Duplicate detection is a binary classification problem by definition, where the algorithm is provided with a pair of records and must classify them as either match or a non-match. Each of the classifications done by the algorithm falls into one of the following categories:

- True Positive (TP): the algorithm correctly identifies a match between two records.

- False Positive (FP): the algorithm incorrectly identifies a match between two records.

- True Negative (TN): the algorithm correctly identifies that two records are not a match.

- False Negative (FN): the algorithm incorrectly identifies that two records are not a match.

The number of matches in each category will determine how well the algorithm performs overall.

Three metrics will be used for evaluation: precision, recall, and F-measure[6]. Precision is the fraction of true positive results among all positive results, thus measuring how accurate the algorithm is at classifying a pair of records as a match. It is defined as:

$$ \text{Precision} = \frac{\frac{T}{P}}{\frac{TP}{FP}} \quad (1) $$

Recall, on the other hand, is the proportion of true positives among all true positives. It is useful to describe how comprehensive the algorithm is in detecting duplicate pairs.

$$ \text{Recall} = \frac{\frac{TP}{TP + FN}}{(2) \quad (3)} $$

For example, if a deduplication tool measures *Recall* = 0.3 and *Precision* = 0.9, then it means it is 90% accurate in its detection of duplicate records, but only identifies 30% of all duplicate records in the database.

The F-measure is a way to combine precision and recall into a single metric, defined as:

$$ \text{F-measure} = 2 \frac{\text{Precision} * \text{Recall}}{\text{Recall}} \quad (3) $$

# 6 Bayesian Approach

The following section presents the Bayesian strategy employed for duplicate detection, along with the tool chosen to implement the pipeline. Each component of the classification pipeline is described in detail, specifying how they contribute to solving the problem.

Many existing tools for record comparison in duplicate detection often rely on a single similarity function and treat all attributes uniformly as strings or character vectors. However, the evaluated approach suggests a departure from this conventional method by using a segmented matching process. This strategy advocates for segmenting the comparison based on the attributes of the listings being evaluated, assigning distinct weights to each segment to obtain an overall matching result.
# 5 Metrics

This section defines the metrics used to evaluate the performance of duplicate detection algorithms. It will explain the insights provided by each metric and how they will be calculated.

Duplicate detection is a binary classification problem by definition, where the algorithm is provided with a pair of records and must classify them as either a match or a non-match. Each of the classifications done by the algorithm falls into one of the following categories:

- True Positive (TP): the algorithm correctly identifies a match between two records.

- False Positive (FP): the algorithm incorrectly identifies a match between two records.

- True Negative (TN): the algorithm correctly identifies that two records are not a match.

- False Negative (FN): the algorithm incorrectly identifies that two records are not a match.

The number of matches in each category will determine how well the algorithm performs overall.

Three metrics will be used for evaluation: precision, recall, and F-measure[6]. Precision is the fraction of true positive results among all positive results, thus measuring how accurate the algorithm is at classifying a pair of records as a match. It is defined as:

$$ \text{Precision} = \frac{\frac{T}{P}}{\frac{TP}{FP}} \quad (1) $$

Recall, on the other hand, is the proportion of true positives among all true positives. It is useful to describe how comprehensive the algorithm is in detecting duplicate pairs.

$$ \text{Recall} = \frac{\frac{TP}{TP + FN}}{(2) \quad (3)} $$

For example, if a deduplication tool measures *Recall* = 0.3 and *Precision* = 0.9, then it means it is 90% accurate in its detection of duplicate records, but only identifies 30% of all duplicate records in the database.

The F-measure is a way to combine precision and recall into a single metric, defined as:

$$ \text{F-measure} = 2 \frac{\text{Precision} * \text{Recall}}{\text{Recall}} \quad (3) $$

# 6 Bayesian Approach

The following section presents the Bayesian strategy employed for duplicate detection, along with the tool chosen to implement the pipeline. Each component of the classification pipeline is described in detail, specifying how they contribute to solving the problem.

Many existing tools for record comparison in duplicate detection often rely on a single similarity function and treat all attributes uniformly as strings or character vectors. However, the evaluated approach suggests a departure from this conventional method by using a segmented matching process. This strategy advocates for segmenting the comparison based on the attributes of the listings being evaluated, assigning distinct weights to each segment to obtain an overall matching result.
To determine whether two listings are duplicates, the approach matches their respective attributes. Then, the two values of each attribute get compared to calculate a similarity score, which is assigned to that attribute. Finally, these scores are combined using Bayes' Theorem to generate an overall similarity score that represents the similarity between the two records. This approach allows for the computation of a probability, based on the available evidence, indicating the likelihood that the records are duplicates. By comparing this probability to the similarity threshold specified by the user, the determination of a match or non-match between the records can be made.

By adopting this approach, a more nuanced and comprehensive evaluation of record similarity is achieved, enabling the generation of probabilistic evidence to support the duplicate detection process. This methodology empowers users with greater control over the threshold for considering records as duplicates.

## 6.1 Duke

Duke<fnref n="5" /> is a powerful and versatile entity resolution engine written in Java. Although it was developed as part of the document archive system Sesam [7], Duke is domain-agnostic, meaning it can be used with data from any domain and structure.

While Duke operates on records as the data entities for deduplication, its out-put consists of links that represent owl: sameAs connections between duplicated records. Duke's duplicate detection process involves three steps, as described below.

First, Duke loads each record in the knowledge base and preprocesses its attributes using Cleaners. These Java objects implement the Cleaner interface and standardize the data by performing operations such as removing extra spaces, converting cases, and removing stop words.

Next, Duke employs a Database implementation to index each record. This allows it to call the function findCandidateMatches(record) for each one of the records, and match them with their most likely pair according to the index criterion.

After the blocking step, Duke matches each record pair by comparing their attributes using a Comparator. Duke's Comparator interface allows for the definition of custom comparison functions that assign similarity scores to record attributes, which are then aggregated into an overall score that represents the similarity between two records. Duke comes with several built-in comparators, including string distance measures like Jaro-Winkler and Levenshtein, and token-based measures like the Dice coefficient and Jackard index. As with the other interfaces, Duke's Comparator interface can be extended to include custom comparison functions that consider domain-specific knowledge and characteristics.

To determine whether two records are duplicates, Duke computes a similarity score between them using the approach described for matching. This similarity score represents the likelihood of the records being duplicates. Subsequently, Duke compares the resulting probability with a user-defined threshold. If the probability exceeds the threshold, the records are classified as duplicates.

## 6.2 Configuration and Similarity Strategies

Detecting duplicates with this Bayesian approach involves employing a combination of similarity functions that consider the nature of the attributes being compared. Different similarity functions are used depending on the attribute type to ensure accurate matching. For instance, when comparing long strings like descriptions, the Levenshtein distance metric proves to be effective. This metric measures the number of character replacements required to transform one text into another. In the context of the real estate knowledge graph, each listing comprises several semantic properties associated with some real estate, such as the description, number of bedrooms, and location. The Bayesian approach leverages the concept of semantic similarity by composing the syntactic similarities among each specific property. This enables a comprehensive evaluation of the complex listings by integrating the results of individual attribute comparisons.

<footnote n="5">⁵ Duke: https://github.com/larsga/Duke/</footnote>
To determine whether two listings are duplicates, the approach matches their respective attributes. Then, the two values of each attribute get compared to calculate a similarity score, which is assigned to that attribute. Finally, these scores are combined using Bayes' Theorem to generate an overall similarity score that represents the similarity between the two records. This approach allows for the computation of a probability, based on the available evidence, indicating the likelihood that the records are duplicates. By comparing this probability to the similarity threshold specified by the user, the determination of a match or non-match between the records can be made.

By adopting this approach, a more nuanced and comprehensive evaluation of record similarity is achieved, enabling the generation of probabilistic evidence to support the duplicate detection process. This methodology empowers users with greater control over the threshold for considering records as duplicates.

## 6.1 Duke

Duke<fnref n="5" /> is a powerful and versatile entity resolution engine written in Java. Although it was developed as part of the document archive system Sesam [7], Duke is domain-agnostic, meaning it can be used with data from any domain and structure.

While Duke operates on records as the data entities for deduplication, its out-put consists of links that represent owl: sameAs connections between duplicated records. Duke's duplicate detection process involves three steps, as described below.

First, Duke loads each record in the knowledge base and preprocesses its attributes using Cleaners. These Java objects implement the Cleaner interface and standardize the data by performing operations such as removing extra spaces, converting cases, and removing stop words.

Next, Duke employs a Database implementation to index each record. This allows it to call the function findCandidateMatches(record) for each one of the records, and match them with their most likely pair according to the index criterion.

After the blocking step, Duke matches each record pair by comparing their attributes using a Comparator. Duke's Comparator interface allows for the definition of custom comparison functions that assign similarity scores to record attributes, which are then aggregated into an overall score that represents the similarity between two records. Duke comes with several built-in comparators, including string distance measures like Jaro-Winkler and Levenshtein, and token-based measures like the Dice coefficient and Jackard index. As with the other interfaces, Duke's Comparator interface can be extended to include custom comparison functions that consider domain-specific knowledge and characteristics.

To determine whether two records are duplicates, Duke computes a similarity score between them using the approach described for matching. This similarity score represents the likelihood of the records being duplicates. Subsequently, Duke compares the resulting probability with a user-defined threshold. If the probability exceeds the threshold, the records are classified as duplicates.

## 6.2 Configuration and Similarity Strategies

Detecting duplicates with this Bayesian approach involves employing a combination of similarity functions that consider the nature of the attributes being compared. Different similarity functions are used depending on the attribute type to ensure accurate matching. For instance, when comparing long strings like descriptions, the Levenshtein distance metric proves to be effective. This metric measures the number of character replacements required to transform one text into another. In the context of the real estate knowledge graph, each listing comprises several semantic properties associated with some real estate, such as the description, number of bedrooms, and location. The Bayesian approach leverages the concept of semantic similarity by composing the syntactic similarities among each specific property. This enables a comprehensive evaluation of the complex listings by integrating the results of individual attribute comparisons.

<footnote n="5">⁵ Duke: https://github.com/larsga/Duke/</footnote>
In configuring the real estate deduplication strategy, an essential component is the utilization of a Lucene<sup>6</sup> database during the blocking step. This step involves executing highly efficient full-text queries to identify potential duplicate candidates. Lucene's indexing and searching capabilities enable the strategy to effectively partition and search through the data, aiding in the identification of records with similar textual information.

In the preprocessing stage, the default cleaners were applied, primarily focusing on tasks such as removing excess spaces and converting text to lowercase. This preparation step ensures consistent and standardized data for further analysis.

During the matching process, a combination of specialized comparators was employed to handle different types of data. For long strings of text, such as descriptions or addresses, the Levenshtein comparator was utilized to measure the similarity between records. Shorter strings like district names were evaluated using the Jaro-Winkler comparator. To handle numerical attributes such as surface area and the number of rooms, dedicated numerical comparators were employed. These comparators use the ratio between the largest and smallest numbers, thus taking into account the numerical significance and proportional- ity of the attributes. Furthermore, a geolocation comparator was employed to assess the distance between two coordinates. If the distance exceeded 100 meters, the records were deemed completely apart, indicating a significant spatial separation. The specific values for the configuration are described in Table 1, which also shows the range of the similarity threshold selected for each variable. These represent the probability of a pair of records being duplicates, given that the values for that attribute are exactly the same or completely different, according to the comparator used. For instance, given that the titles of two real estate listings are exactly the same, the probability that the listings refer to the same entity is 70%. Similarly, if the titles are completely different, that probability reduces to 19%. The probabilities calculated for each attribute are the ones that get reduced to a single number using Bayes' Theorem.

The ranges for each attribute were selected based on how helpful they are in distinguishing between listings. For instance, if an attribute such as the title or price is very informative, it was given a wider range. This means that if two listings have the same value for that attribute, they are likely to be the same, and if they have very different values, they are likely to be different listings.

In the Bayesian approach used, probabilities closer to 0 or 1 are considered more important than those closer to 0.5. For example, the fact that two listings have the same covered surface value does not provide much information to determine if they are referring to the same or a different entity. However, if they have completely different covered surface values, they are more likely to be different listings. For that reason, the similarity threshold for the covered surface ranges from 0.09, which means that the probability of two listings being the same is 9%, to 0.55, which means the algorithm should not give it much importance. This range is set based on the degree of impact each attribute has on the similarity calculation.

<footnote n="6"><sup>6</sup> Lucene: https://lucene.apache.org/</footnote>
In configuring the real estate deduplication strategy, an essential component is the utilization of a Lucene<fnref n="6" /> database during the blocking step. This step involves executing highly efficient full-text queries to identify potential duplicate candidates. Lucene’s indexing and searching capabilities enable the strategy to effectively partition and search through the data, aiding in the identification of records with similar textual information.

In the preprocessing stage, the default cleaners were applied, primarily focusing on tasks such as removing excess spaces and converting text to lowercase. This preparation step ensures consistent and standardized data for further analysis.

During the matching process, a combination of specialized comparators was employed to handle different types of data. For long strings of text, such as descriptions or addresses, the Levenshtein comparator was utilized to measure the similarity between records. Shorter strings like district names were evaluated using the Jaro-Winkler comparator. To handle numerical attributes such as surface area and the number of rooms, dedicated numerical comparators were employed. These comparators use the ratio between the largest and smallest numbers, thus taking into account the numerical significance and proportionality of the attributes. Furthermore, a geolocation comparator was employed to assess the distance between two coordinates. If the distance exceeded 100 meters, the records were deemed completely apart, indicating a significant spatial separation. The specific values for the configuration are described in Table 1, which also shows the range of the similarity threshold selected for each variable. These represent the probability of a pair of records being duplicates, given that the values for that attribute are exactly the same or completely different, according to the comparator used. For instance, given that the titles of two real estate listings are exactly the same, the probability that the listings refer to the same entity is 70%. Similarly, if the titles are completely different, that probability reduces to 19%. The probabilities calculated for each attribute are the ones that get reduced to a single number using Bayes’ Theorem.

The ranges for each attribute were selected based on how helpful they are in distinguishing between listings. For instance, if an attribute such as the title or price is very informative, it was given a wider range. This means that if two listings have the same value for that attribute, they are likely to be the same, and if they have very different values, they are likely to be different listings.

In the Bayesian approach used, probabilities closer to 0 or 1 are considered more important than those closer to 0.5. For example, the fact that two listings have the same covered surface value does not provide much information to determine if they are referring to the same or a different entity. However, if they have completely different covered surface values, they are more likely to be different listings. For that reason, the similarity threshold for the covered surface ranges from 0.09, which means that the probability of two listings being the same is 9%, to 0.55, which means the algorithm should not give it much importance. This range is set based on the degree of impact each attribute has on the similarity calculation.

<footnote n="6">⁶ Lucene: https://lucene.apache.org/</footnote>
<table><caption>**Table 1. Configuration used to detect duplicates in the knowledge graph.**</caption><thead><tr><th>Attributes</th><th>Compar<br>or</th><th>Min. similarity<br>threshold</th><th>Max. similarity<br>threshold</th></tr></thead><tbody><tr><td>Title</td><td>Levensht<br>ein</td><td>0.19</td><td>0.90</td></tr><tr><td>Description</td><td>Levensht<br>ein</td><td>0.39</td><td>0.70</td></tr><tr><td>Price</td><td>Numeric</td><td>0.05</td><td>0.80</td></tr><tr><td>Maintenance fee</td><td>Numeric</td><td>0.05</td><td>0.60</td></tr><tr><td>Property type</td><td>Exact</td><td>0.10</td><td>0.56</td></tr><tr><td>Age</td><td>Exact</td><td>0.07</td><td>0.50</td></tr><tr><td>Coordinates</td><td>Geoposi<br>on</td><td>0.20</td><td>0.80</td></tr><tr><td>Address</td><td>Levensht<br>ein</td><td>0.09</td><td>0.90</td></tr><tr><td>District</td><td>Jaro-<br>Winkler</td><td>0.39</td><td>0.51</td></tr><tr><td>Total surface</td><td>Numeric</td><td>0.10</td><td>0.67</td></tr><tr><td>Covered surface</td><td>Numeric</td><td>0.09</td><td>0.55</td></tr><tr><td>Land surface</td><td>Numeric</td><td>0.07</td><td>0.60</td></tr><tr><td>Amount of rooms</td><td>Exact</td><td>0.10</td><td>0.61</td></tr><tr><td>Amount of<br>bathrooms</td><td>Exact</td><td>0.17</td><td>0.51</td></tr><tr><td>Amount of garages</td><td>Exact</td><td>0.10</td><td>0.60</td></tr><tr><td>Amount of<br>bedrooms</td><td>Exact</td><td>0.10</td><td>0.60</td></tr></tbody></table>

# 7 Evaluation

This section will evaluate the performance of the duplicate detection strategy presented previously over a real estate listing knowledge base. The creation of a ground truth dataset using expert labelling will be explained first. Then, the results of the evaluation will be presented, followed by a discussion of the performances achieved by the Bayesian strategy.

## 7.1 Ground Truth Dataset Generation

The term ground truth refers to a dataset that contains reliable information used as a standard for evaluating different algorithms. The ground truth dataset used in this study was generated to measure the performance of the duplicate detection strategy presented earlier. It comprises two separate files: a knowledge base that contains all the information about each real estate listing, and a linkfile that specifies which listings are duplicates of one another.

To create this ground truth dataset, a team of experts began by using a web scraping tool to generate a knowledge base of real estate listings. To minimize the risk of missing any duplicates, the dataset was divided into smaller subparts based on the listings' proximity, as determined by their latitude and longitude. The experts manually reviewed each subpart to identify duplicates, comparing various attributes such as title, description, price, number of bedrooms, age, type of property, and address. They recorded the duplicates found in a spreadsheet, resulting in 3688 rows, each representing a set of listings that were duplicates of each other. Each set may contain two or more listings since multiple listings can represent the same property. The experts then removed any listings that were not labelled on the spreadsheet, resulting in a smaller knowledge base of 9333 listings.

To create the ground truth dataset, a script was developed to randomize the spreadsheet and split it in half. One half represented duplicates, while the other half represented non-duplicates. The first half was used to create a new knowledge base containing listings known to be duplicated, and the link file recorded which listings were duplicates of each other. For the second half, one random listing was selected from each set to be part of the new knowledge base, while the other listings were deleted. This ensured that the selected listings had no known duplicates in the new database.
<table><caption>**Table 1. Configuration used to detect duplicates in the knowledge graph.**</caption><thead><tr><th>Attributes</th><th>Compar<br>or</th><th>Min. similarity<br>threshold</th><th>Max. similarity<br>threshold</th></tr></thead><tbody><tr><td>Title</td><td>Levensht<br>ein</td><td>0.19</td><td>0.90</td></tr><tr><td>Description</td><td>Levensht<br>ein</td><td>0.39</td><td>0.70</td></tr><tr><td>Price</td><td>Numeric</td><td>0.05</td><td>0.80</td></tr><tr><td>Maintenance fee</td><td>Numeric</td><td>0.05</td><td>0.60</td></tr><tr><td>Property type</td><td>Exact</td><td>0.10</td><td>0.56</td></tr><tr><td>Age</td><td>Exact</td><td>0.07</td><td>0.50</td></tr><tr><td>Coordinates</td><td>Geoposi<br>tion</td><td>0.20</td><td>0.80</td></tr><tr><td>Address</td><td>Levensht<br>ein</td><td>0.09</td><td>0.90</td></tr><tr><td>District</td><td>Jaro-<br>Winkler</td><td>0.39</td><td>0.51</td></tr><tr><td>Total surface</td><td>Numeric</td><td>0.10</td><td>0.67</td></tr><tr><td>Covered surface</td><td>Numeric</td><td>0.09</td><td>0.55</td></tr><tr><td>Land surface</td><td>Numeric</td><td>0.07</td><td>0.60</td></tr><tr><td>Amount of rooms</td><td>Exact</td><td>0.10</td><td>0.61</td></tr><tr><td>Amount of<br>bathrooms</td><td>Exact</td><td>0.17</td><td>0.51</td></tr><tr><td>Amount of garages</td><td>Exact</td><td>0.10</td><td>0.60</td></tr><tr><td>Amount of<br>bedrooms</td><td>Exact</td><td>0.10</td><td>0.60</td></tr></tbody></table>

# 7 Evaluation

This section will evaluate the performance of the duplicate detection strategy presented previously over a real estate listing knowledge base. The creation of a ground truth dataset using expert labelling will be explained first. Then, the results of the evaluation will be presented, followed by a discussion of the performances achieved by the Bayesian strategy.

## 7.1 Ground Truth Dataset Generation

The term ground truth refers to a dataset that contains reliable information used as a standard for evaluating different algorithms. The ground truth dataset used in this study was generated to measure the performance of the duplicate detection strategy presented earlier. It comprises two separate files: a knowledge base that contains all the information about each real estate listing, and a linkfile that specifies which listings are duplicates of one another.

To create this ground truth dataset, a team of experts began by using a web scraping tool to generate a knowledge base of real estate listings. To minimize the risk of missing any duplicates, the dataset was divided into smaller subparts based on the listings' proximity, as determined by their latitude and longitude. The experts manually reviewed each subpart to identify duplicates, comparing various attributes such as title, description, price, number of bedrooms, age, type of property, and address. They recorded the duplicates found in a spreadsheet, resulting in 3688 rows, each representing a set of listings that were duplicates of each other. Each set may contain two or more listings since multiple listings can represent the same property. The experts then removed any listings that were not labelled on the spreadsheet, resulting in a smaller knowledge base of 9333 listings.

To create the ground truth dataset, a script was developed to randomize the spreadsheet and split it in half. One half represented duplicates, while the other half represented non-duplicates. The first half was used to create a new knowledge base containing listings known to be duplicated, and the link file recorded which listings were duplicates of each other. For the second half, one random listing was selected from each set to be part of the new knowledge base, while the other listings were deleted. This ensured that the selected listings had no known duplicates in the new database.
## 7.2 Results

The performance of the duplicate detection strategy was evaluated using the ground truth dataset described above. Duke's output was compared with the links file in the ground truth dataset, and precision, recall, and F-measure were used as performance metrics.

The ground truth file contained 6543 records, and our strategy was able to find 3139 out of 4455 correct links, resulting in a recall of approximately 70.4%. However, it's important to note that the strategy also found 1554 links that were not in the ground truth, resulting in a precision of only 66.8%. Overall, that leads to an F-measure of 68.6%.

This finding is interesting and could be attributed to various factors. For instance, if the real estate listings were published by the same agency, it's possible that they used text templates for the description and title of the listing, leading to a higher number of false positives. In this case, it may be worth evaluating a different configuration with lower weights on these variables. Another approach could be to use a deduplication strategy that's more flexible and doesn't rely solely on Bayesian classification, which assumes that the probabilities given by each variable are independent. For example, such a strategy could assign a smaller weight to the description variable, since listings published by the same agent are likely to have similar descriptions.

Regarding the coordinates of the listings, it was found that real estate agents may not use the actual latitude and longitude of the property, either marking a point nearby or using the location of the agency itself. This can lead to many records having similar coordinate values, although they refer to different properties. Therefore, the fact that two coordinates are different or the same doesn't necessarily confirm or discard a match, respectively.

However, it cannot be confirmed that missed duplicates are actually wrong, as it is also possible that the strategy was able to find duplicate listings that the experts who created the ground truth dataset overlooked. Although this file can serve as a representative sample of the larger real estate listings knowledge base, identifying this many duplicates can be challenging, which may have led to errors in the ground truth dataset. This underscores the importance of refining the duplicate detection strategy for this domain to improve the accuracy of the results.

## 8 Conclusions and Future Work

This study assessed a duplicate detection strategy applied to a real estate knowledge graph compiled from various sources. The approach involved computing a probability score indicating the likelihood of two records being duplicates, allowing for the identification of implicit owl: sameAs links between them. The evaluation of this approach resulted in a precision of 66.8%, recall of 70.4%, and F-measure of 68.6%. By segmenting the record comparison process based on the considered attributes and assigning weights to each segment, the strategy effectively addressed the challenge of duplicate detection. Furthermore, the approach demonstrated its ability to cleanse the knowledge graph by eliminating noisy data, thereby enhancing the quality and reliability of the real estate information available for analysis within the domain.

The strategy was evaluated by employing a ground truth dataset created by a domain expert, which consisted of a real estate listing knowledge graph with duplicate and unique entities, as well as a links file that identified the missing owl: sameAs links in the dataset.

In the future, alternative configurations will be explored to enhance the overall accuracy of the presented approach and to identify more duplicates. Additionally, other techniques for detecting duplicate real estate listings, such as graph structural analysis, window sliding, graph embedding, and machine learning-driven solutions, will be experimented with.
## 7.2 Results

The performance of the duplicate detection strategy was evaluated using the ground truth dataset described above. Duke's output was compared with the links file in the ground truth dataset, and precision, recall, and F-measure were used as performance metrics.

The ground truth file contained 6543 records, and our strategy was able to find 3139 out of 4455 correct links, resulting in a recall of approximately 70.4%. However, it's important to note that the strategy also found 1554 links that were not in the ground truth, resulting in a precision of only 66.8%. Overall, that leads to an F-measure of 68.6%.

This finding is interesting and could be attributed to various factors. For instance, if the real estate listings were published by the same agency, it's possible that they used text templates for the description and title of the listing, leading to a higher number of false positives. In this case, it may be worth evaluating a different configuration with lower weights on these variables. Another approach could be to use a deduplication strategy that's more flexible and doesn't rely solely on Bayesian classification, which assumes that the probabilities given by each variable are independent. For example, such a strategy could assign a smaller weight to the description variable, since listings published by the same agent are likely to have similar descriptions.

Regarding the coordinates of the listings, it was found that real estate agents may not use the actual latitude and longitude of the property, either marking a point nearby or using the location of the agency itself. This can lead to many records having similar coordinate values, although they refer to different properties. Therefore, the fact that two coordinates are different or the same doesn't necessarily confirm or discard a match, respectively.

However, it cannot be confirmed that missed duplicates are actually wrong, as it is also possible that the strategy was able to find duplicate listings that the experts who created the ground truth dataset overlooked. Although this file can serve as a representative sample of the larger real estate listings knowledge base, identifying this many duplicates can be challenging, which may have led to errors in the ground truth dataset. This underscores the importance of refining the duplicate detection strategy for this domain to improve the accuracy of the results.

## 8 Conclusions and Future Work

This study assessed a duplicate detection strategy applied to a real estate knowledge graph compiled from various sources. The approach involved computing a probability score indicating the likelihood of two records being duplicates, allowing for the identification of implicit owl: sameAs links between them. The evaluation of this approach resulted in a precision of 66.8%, recall of 70.4%, and F-measure of 68.6%. By segmenting the record comparison process based on the considered attributes and assigning weights to each segment, the strategy effectively addressed the challenge of duplicate detection. Furthermore, the approach demonstrated its ability to cleanse the knowledge graph by eliminating noisy data, thereby enhancing the quality and reliability of the real estate information available for analysis within the domain.

The strategy was evaluated by employing a ground truth dataset created by a domain expert, which consisted of a real estate listing knowledge graph with duplicate and unique entities, as well as a links file that identified the missing owl: sameAs links in the dataset.

In the future, alternative configurations will be explored to enhance the overall accuracy of the presented approach and to identify more duplicates. Additionally, other techniques for detecting duplicate real estate listings, such as graph structural analysis, window sliding, graph embedding, and machine learning-driven solutions, will be experimented with.
References

1. Assi, A., Mcheick, H., Dhifli, W.: Data linking over RDF knowledge graphs: A survey. Concurrency and Computation: Practice and Experience 32(19), e5746 (2020).

2. Barlaug, N., Gulla, J.A.: Neural Networks for Entity Matching: A Survey. ACM Transactions on Knowledge Discovery from Data 15(3), 1–37 (Jun 2021). https://doi.org/10.1145/3442200

3. Batini, C., Scannapieco, M.: Data Quality: Concepts, Methodologies and Tech-niques. Springer Science & Business Media (Jan 2006).

4. Dong, X.L., Berti-Equille, L., Srivastava, D.: Integrating conflicting data: the role of source dependence. Proceedings of the VLDB Endowment 2(1), 550–561 (Aug 2009). https://doi.org/10.14778/1687627.1687690, https://dl.acm.org/doi/10.14778/1687627.1687690

5. Elmagarmid, A., Ipeirotis, P., Verykios, V.: Duplicate Record Detection: A Survey. Knowledge and Data Engineering, IEEE Transactions on 19, 1–16 (Feb 2007). https://doi.org/10.1109/TKDE.2007.250581

6. Ferrara, A., Lorusso, D., Montanelli, S., Varese, G.: Towards a Benchmark for Instance Matching. The 7th International Semantic Web Conference p. 13 (Jan 2008)

7. Garshol, L.M., Borge, A.: Hafslund Sesam – An Archive on Semantics. In: The Semantic Web: Semantics and Big Data, vol. 7882, pp. 578–592. Springer, Berlin, Heidelberg (2013).

8. Hammar, K., Wallin, E.O., Karlberg, P., Hälleberg, D.: The RealEstateCore Ontology. In: Ghidini, C., Hartig, O., Maleshkova, M., Svátek, V., Cruz, I., Hogan, A., Song, J., Lefrançois, M., Gandon, F. (eds.) The Semantic Web – ISWC 2019, vol. 11779, pp. 130–145. Springer International Publishing, Cham (2019). https://doi.org/10.1007/978-3-030-30796-7_9, https://link.springer.com/10.1007/978-3-030-30796-7_9, series Title: Lecture Notes in Computer Science

9. Huaman, E., Kärle, E., Fensel, D.: Duplication Detection in Knowledge Graphs: Literature and Tools. arXiv:2004.08257 [cs] (Apr 2020), arXiv: 2004.08257

10. Huang, Y., Chiang, F.: Refining Duplicate Detection for Improved Data Quality. TDDL/MDQual/Futurity@ TPDL (2017)

11. Koumarelas, I., Papenbrock, T., Naumann, F.: MDedup: duplicate detection with matching dependencies. Proceedings of the VLDB Endowment 13(5), 712–725 (Jan 2020).

12. Manku, G.S., Jain, A., Das Sarma, A.: Detecting near-duplicates for web crawling. In: Proceedings of the 16th international conference on World Wide Web. pp. 141–150. ACM, Banff Alberta Canada (May 2007). https://doi.org/10.1145/1242572.1242592, https://dl.acm.org/doi/10.1145/1242572.1242592

13. Mel, A., Kang, B., Lijffijt, J., De Bie, T.: FONDUE: A Framework for Node Disambiguation and Deduplication Using Network Embeddings. Applied Sciences 11(21), 9884 (Jan 2021). https://doi.org/10.3390/app11219884, number: 21 Publisher: Multidisciplinary Digital Publishing Institute

14. Niu, J., Niu, P.: An intelligent automatic valuation system for real estate based on machine learning. In: Proceedings of the International Conference on Artificial Intelligence, Information Processing and Cloud Computing. pp. 1–6. ACM, Sanya China (Dec 2019). https://doi.org/10.1145/3371425.3371454, https://dl.acm.org/doi/10.1145/3371425.3371454

15. Zhu, H., Wang, X., Jiang, Y., Fan, H., Du, B., Liu, Q.: FTRLIM: Distributed Instance Matching Framework for Large-Scale Knowledge Graph Fusion. Entropy 23(5), 602 (May 2021). https://doi.org/10.3390/e23050602

16. Zong, W., Wu, F., Chu, L.K., Sculli, D.: Identification of approximately duplicate material records in ERP systems. Enterprise Information Systems 11(3), 434–451 (Mar 2017). https://doi.org/10.1080/17517575.2015.1065513, https://www.tandfonline.com/doi/full/10.1080/17517575.2015.1065513
References

1. Assi, A., Mcheick, H., Dhifli, W.: Data linking over RDF knowledge graphs: A survey. Concurrency and Computation: Practice and Experience **32**(19), e5746 (2020).

2. Barlaug, N., Gulla, J.A.: Neural Networks for Entity Matching: A Survey. ACM Transactions on Knowledge Discovery from Data **15**(3), 1–37 (Jun 2021). https://doi.org/10.1145/3442200

3. Batini, C., Scannapieco, M.: Data Quality: Concepts, Methodologies and Tech-niques. Springer Science & Business Media (Jan 2006).

4. Dong, X.L., Berti-Equille, L., Srivastava, D.: Integrating conflicting data: the role of source dependence. Proceedings of the VLDB Endowment **2**(1), 550–561 (Aug 2009). https://doi.org/10.14778/1687627.1687690, https://dl.acm.org/doi/10.14778/1687627.1687690

5. Elmagarmid, A., Ipeirotis, P., Verykios, V.: Duplicate Record Detection: A Survey. Knowledge and Data Engineering, IEEE Transactions on **19**, 1–16 (Feb 2007). https://doi.org/10.1109/TKDE.2007.250581

6. Ferrara, A., Lorusso, D., Montanelli, S., Varese, G.: Towards a Benchmark for Instance Matching. The 7th International Semantic Web Conference p. 13 (Jan 2008)

7. Garshol, L.M., Borge, A.: Hafslund Sesam – An Archive on Semantics. In: The Semantic Web: Semantics and Big Data, vol. 7882, pp. 578–592. Springer, Berlin, Heidelberg (2013).

8. Hammar, K., Wallin, E.O., Karlberg, P., Hälleberg, D.: The RealEstateCore Ontology. In: Ghidini, C., Hartig, O., Maleshkova, M., Svátek, V., Cruz, I., Hogan, A., Song, J., Lefrançois, M., Gandon, F. (eds.) The Semantic Web – ISWC 2019, vol. 11779, pp. 130–145. Springer International Publishing, Cham (2019). https://doi.org/10.1007/978-3-030-30796-7_9, https://link.springer.com/10.1007/978-3-030-30796-7_9, series Title: Lecture Notes in Computer Science

9. Huaman, E., Kärle, E., Fensel, D.: Duplication Detection in Knowledge Graphs: Literature and Tools. arXiv:2004.08257 [cs] (Apr 2020), arXiv: 2004.08257

10. Huang, Y., Chiang, F.: Refining Duplicate Detection for Improved Data Quality. TDDL/MDQual/Futurity@ TPDL (2017)

11. Koumarelas, I., Papenbrock, T., Naumann, F.: MDedup: duplicate detection with matching dependencies. Proceedings of the VLDB Endowment **13**(5), 712–725 (Jan 2020).

12. Manku, G.S., Jain, A., Das Sarma, A.: Detecting near-duplicates for web crawling. In: Proceedings of the 16th international conference on World Wide Web. pp. 141–150. ACM, Banff Alberta Canada (May 2007). https://doi.org/10.1145/1242572.1242592, https://dl.acm.org/doi/10.1145/1242572.1242592

13. Mel, A., Kang, B., Lijffijt, J., De Bie, T.: FONDUE: A Framework for Node Disambiguation and Deduplication Using Network Embeddings. Applied Sciences **11**(21), 9884 (Jan 2021). https://doi.org/10.3390/app11219884, number: 21 Publisher: Multidisciplinary Digital Publishing Institute

14. Niu, J., Niu, P.: An intelligent automatic valuation system for real estate based on machine learning. In: Proceedings of the International Conference on Artificial Intelligence, Information Processing and Cloud Computing. pp. 1–6. ACM, Sanya China (Dec 2019). https://doi.org/10.1145/3371425.3371454, https://dl.acm.org/doi/10.1145/3371425.3371454

15. Zhu, H., Wang, X., Jiang, Y., Fan, H., Du, B., Liu, Q.: FTRLIM: Distributed Instance Matching Framework for Large-Scale Knowledge Graph Fusion. Entropy **23**(5), 602 (May 2021). https://doi.org/10.3390/e23050602

16. Zong, W., Wu, F., Chu, L.K., Sculli, D.: Identification of approximately duplicate material records in ERP systems. Enterprise Information Systems **11**(3), 434–451 (Mar 2017). https://doi.org/10.1080/17517575.2015.1065513, https://www.tandfonline.com/doi/full/10.1080/17517575.2015.1065513
# Identification of Collaboration issues during the adoption of Scrum in Software development teams

Ingrith C. Muñoz¹, César A. Collazos¹ and Julio A. Hurtado¹

¹ IDIS Research Group, University of Cauca, 190001, Popayán, Colombia.
{ingrithc, ccollazo, ahurtado}@unicauca.edu.co

**Abstract.** Scrum is one of the most popular agile methodologies for software development, and its use in software development teams has been increasing in recent years. This increased use of Scrum is due in part to the benefits it offers, such as greater flexibility, greater collaboration among team members, and greater ability to adapt to changing project requirements.

Scrum is based on collaborative work among team members to achieve project goals, since team members are expected to work together interactively and col- laboratively to achieve these goals. Due to the above, collaboration issues ac- quire a relevant role, since they can have a significant impact on the Scrum adoption process. This article presents the collaboration problems encountered in software development teams during the Scrum adoption process identified through semi-structured interviews conducted with leaders of software devel- opment teams adopting Scrum.

**Keywords:** Scrum, Adoption, Collaboration, Issues.

## 1 Introduction

Agile methodologies are a software product development approach characterized by its flexibility [1] [2]. One of the most used agile methodologies is Scrum [3], which is a framework for the agile management of software projects; the use of agile methodologies and specifically Scrum has become more and more frequent in small software development organizations [4] [5]. However, the lack of understanding of Scrum during its adoption has led to multiple drawbacks or obstacles [4], even when the team has received training in this framework [6]. Due to the above, the scientific community has tried to establish the determining factors in the adoption of Scrum [7], in order to serve as support in an adoption initiative.

Among the critical factors associated with Scrum adoption difficulties are those re-lated to human behavior (personality, beliefs, culture, etc.), hereinafter the person factor [8] [7]; which is critical in the agile context considering that one of its princi- ples promulgates: "Individuals and their interactions, about processes and tools. This implies that great importance should be given to factors such as communication, in-teraction, integration, organizational culture, companionship and collaboration [9].

Particularly, collaboration is an important factor in software development, since it is an effective means to achieve business objectives and increase performance, for this reason, collaborative practices acquire great value today for the software industry. Collaboration issues in software development teams can have a significant impact on the Scrum adoption process. In Scrum, collaboration is critical to team success, as team members are expected to work together interactively and collaboratively to achieve project goals [7]. If there are team collaboration issues, this can affect the effectiveness of Scrum, as team members may find it difficult to work together and achieve project goals. For example, if there is a lack of communication in the team, there can be coordination and cooperation problems, which can delay the develop- ment process. Similarly, if team members are not committed to the Scrum process, there may be a lack of motivation and enthusiasm, which can affect the quality of work and customer satisfaction. Therefore, it is important to address team collabora- tion issues to ensure a successful Scrum adoption.
# Identification of Collaboration issues during the adoption of Scrum in Software development teams

Ingrith C. Muñoz¹, César A. Collazos¹ and Julio A. Hurtado¹

¹ IDIS Research Group, University of Cauca, 190001, Popayán, Colombia.
{ingrithc, ccollazo, ahurtado}@unicauca.edu.co

**Abstract.** Scrum is one of the most popular agile methodologies for software development, and its use in software development teams has been increasing in recent years. This increased use of Scrum is due in part to the benefits it offers, such as greater flexibility, greater collaboration among team members, and greater ability to adapt to changing project requirements.

Scrum is based on collaborative work among team members to achieve project goals, since team members are expected to work together interactively and col- laboratively to achieve these goals. Due to the above, collaboration issues ac- quire a relevant role, since they can have a significant impact on the Scrum adoption process. This article presents the collaboration problems encountered in software development teams during the Scrum adoption process identified through semi-structured interviews conducted with leaders of software devel- opment teams adopting Scrum.

**Keywords:** Scrum, Adoption, Collaboration, Issues.

## 1 Introduction

Agile methodologies are a software product development approach characterized by its flexibility [1] [2]. One of the most used agile methodologies is Scrum [3], which is a framework for the agile management of software projects; the use of agile methodologies and specifically Scrum has become more and more frequent in small software development organizations [4] [5]. However, the lack of understanding of Scrum during its adoption has led to multiple drawbacks or obstacles [4], even when the team has received training in this framework [6]. Due to the above, the scientific community has tried to establish the determining factors in the adoption of Scrum [7], in order to serve as support in an adoption initiative.

Among the critical factors associated with Scrum adoption difficulties are those re-lated to human behavior (personality, beliefs, culture, etc.), hereinafter the person factor [8] [7]; which is critical in the agile context considering that one of its princi- ples promulgates: "Individuals and their interactions, about processes and tools. This implies that great importance should be given to factors such as communication, in-teraction, integration, organizational culture, companionship and collaboration [9].

Particularly, collaboration is an important factor in software development, since it is an effective means to achieve business objectives and increase performance, for this reason, collaborative practices acquire great value today for the software industry. Collaboration issues in software development teams can have a significant impact on the Scrum adoption process. In Scrum, collaboration is critical to team success, as team members are expected to work together interactively and collaboratively to achieve project goals [7]. If there are team collaboration issues, this can affect the effectiveness of Scrum, as team members may find it difficult to work together and achieve project goals. For example, if there is a lack of communication in the team, there can be coordination and cooperation problems, which can delay the develop- ment process. Similarly, if team members are not committed to the Scrum process, there may be a lack of motivation and enthusiasm, which can affect the quality of work and customer satisfaction. Therefore, it is important to address team collabora- tion issues to ensure a successful Scrum adoption.
Due to the above, there is a need to understand and identify the collaboration issues faced by software development teams during the adoption of Scrum.

This article presents in section 2 a state of the art and related works, in section 3 presents a study for the identification of collaboration factors that affect the adoption of Scrum and in section 4 the conclusions and future work.

# 2 Background

## 2.1 Agile methods

Agile methods are a set of techniques for project management and software development. They emerged as an effort to improve perceived and real weaknesses of conventional software engineering [8], but have also been extended to other types of projects. Agile methods comply with a number of principles and values stated in the agile manifesto [8]. In addition, agile methods are attentive to the project environment and stakeholders, offer a more open working environment and a much more flexible framework [1] [2].

### Scrum

Scrum is an agile project management methodology specifically referred to software engineering [3]. Since it has a flexible adaptation to change, it is recommended for use in complex projects with changing or poorly defined requirements, where early and highly complex deliverables are needed. Scrum focuses on how the team members should work so that the system is flexible and adapts to constantly changing conditions, therefore, its operation is based on their roles, events, artifacts and associated rules.

### Scrum adoption

Scrum adoption refers to the process of implementing and using the Scrum agile methodology in a software development team [10]. Scrum adoption may involve making changes to the organizational culture, training team members, implementing new tools and processes, and managing change at the organizational level [10].

The adoption of Scrum gives greater importance to people and their relationships, i.e., adoption must be a voluntary and conscious decision to internalize not only the Scrum process and methodology, but also the agile values and principles, so that the team's thinking changes, and to influence change in the organizational culture. Consequently, adoption generates a shared vision of the process, the agile values and principles, and the organizational culture.

## 2.2 Collaboration

Collaboration is working together to achieve a task or objective that would not be achieved individually under the same time, effort and cost constraints [11]. A collaborative team is a group of people with complementary skills who share tasks, resources, responsibilities and leadership, to achieve a common understanding that allows them to achieve a common goal [12], which is achieved if and only if all members achieve their individual goal [13].

Achieving collaboration in software engineering teams includes (1) adequate communication of requirements, design decisions, tasks, changes, among others; (2) group awareness of what each participant is doing and the current status of the project, their availability and knowledge; and (3) appropriate interactions to coordinate and perform tasks [14].
Due to the above, there is a need to understand and identify the collaboration issues faced by software development teams during the adoption of Scrum.

This article presents in section 2 a state of the art and related works, in section 3 presents a study for the identification of collaboration factors that affect the adoption of Scrum and in section 4 the conclusions and future work.

# 2 Background

## 2.1 Agile methods

Agile methods are a set of techniques for project management and software development. They emerged as an effort to improve perceived and real weaknesses of conventional software engineering [8], but have also been extended to other types of projects. Agile methods comply with a number of principles and values stated in the agile manifesto [8]. In addition, agile methods are attentive to the project environment and stakeholders, offer a more open working environment and a much more flexible framework [1] [2].

### Scrum

Scrum is an agile project management methodology specifically referred to software engineering [3]. Since it has a flexible adaptation to change, it is recommended for use in complex projects with changing or poorly defined requirements, where early and highly complex deliverables are needed. Scrum focuses on how the team members should work so that the system is flexible and adapts to constantly changing conditions, therefore, its operation is based on their roles, events, artifacts and associated rules.

### Scrum adoption

Scrum adoption refers to the process of implementing and using the Scrum agile methodology in a software development team [10]. Scrum adoption may involve making changes to the organizational culture, training team members, implementing new tools and processes, and managing change at the organizational level [10].

The adoption of Scrum gives greater importance to people and their relationships, i.e., adoption must be a voluntary and conscious decision to internalize not only the Scrum process and methodology, but also the agile values and principles, so that the team's thinking changes, and to influence change in the organizational culture. Consequently, adoption generates a shared vision of the process, the agile values and principles, and the organizational culture.

## 2.2 Collaboration

Collaboration is working together to achieve a task or objective that would not be achieved individually under the same time, effort and cost constraints [11]. A collaborative team is a group of people with complementary skills who share tasks, resources, responsibilities and leadership, to achieve a common understanding that allows them to achieve a common goal [12], which is achieved if and only if all members achieve their individual goal [13].

Achieving collaboration in software engineering teams includes (1) adequate communication of requirements, design decisions, tasks, changes, among others; (2) group awareness of what each participant is doing and the current status of the project, their availability and knowledge; and (3) appropriate interactions to coordinate and perform tasks [14].
## 2.3 Existing work

L. V. Araujo and A. N. Castrillón [15] conducted a study of the main factors, problems, challenges, risks and situations that affect the adoption of Scrum through inter-views with groups of experts in order to make a roadmap for the adoption of Scrum.

N. Khan, N. Ikram, and S. Imtiaz [7] focuses on the common problem of software development teams of having a large number of items in their backlog, also known as backlog. The article presents Scrum as a methodology that can help teams solve this problem and improve software development efficiency. The authors describe how Scrum helps teams prioritize and organize their backlog, and how teams can work together more effectively to achieve project goals. In addition, the author highlights the importance of communication and collaboration in the Scrum implementation process. The article concludes that adopting Scrum can be an effective solution to backlog problems and can improve the productivity and quality of the developed software. Overall, they propose a solution to backlog problems during Scrum adoption. The study focuses on a development team, and applies interviews for information gathering, in addition, it uses notes and project management tools for backlog monitoring.

Irum Inayat and Siti Salwah [16], propose a framework to study requirements- driven collaboration in distributed agile teams and determine the impact of their collaboration patterns during iteration, defining collaboration in terms of communication as information sharing among team members and awareness of each other's knowledge. The authors conducted two case studies on agile teams, whose information was collected through questionnaires, semi-structured interviews and observation. Furthermore, the authors conclude that the proposed framework may be useful for researching and improving collaboration in the future. Overall, the article provides valuable insight into collaboration in agile teams and how to improve it to achieve success in agile projects.

Batra, Weidong and Mingyu [17] explore the concept of collaboration in the context of agile software development. The authors define collaboration as an interactive process in which team members work together to achieve common goals and identify four key dimensions of collaboration in agile software development: communication, coordination, cooperation, and commitment. Each dimension is examined in detail, and factors that can affect collaboration in each area are highlighted. The authors also describe the benefits of collaboration in agile software development, including increased efficiency, improved product quality, and increased customer satisfaction. The authors note that there is little research examining the nature and dimensions of collaboration in the context of agile software development. Interview data collected from five software development outsourcing providers in China were used to develop this paper.

# 3 Qualitative Study on the collaborative aspects taken into account by development teams during Scrum adoption

In many organizations, drawbacks have been found when adopting Scrum as a framework in their projects [4], these are related to factors associated with human behavior such as culture, organizational, interaction, companionship, communication, etc [10]. Next, the main problems and situations that arise during the adoption of Scrum are consolidated according to the empirical perspective of work team leaders. These problems will make it possible to identify the collaborative aspects that the team recognizes and which of them represent weaknesses in both the collaborative factors and the methodology.

## 3.1 Design

**Research question:** What are the collaborative aspects that software companies identify during Scrum adoption and how well do they cover collaboration-related features?
## 2.3 Existing work

L. V. Araujo and A. N. Castrillón [15] conducted a study of the main factors, problems, challenges, risks and situations that affect the adoption of Scrum through inter-views with groups of experts in order to make a roadmap for the adoption of Scrum.

N. Khan, N. Ikram, and S. Imtiaz [7] focuses on the common problem of software development teams of having a large number of items in their backlog, also known as backlog. The article presents Scrum as a methodology that can help teams solve this problem and improve software development efficiency. The authors describe how Scrum helps teams prioritize and organize their backlog, and how teams can work together more effectively to achieve project goals. In addition, the author highlights the importance of communication and collaboration in the Scrum implementation process. The article concludes that adopting Scrum can be an effective solution to backlog problems and can improve the productivity and quality of the developed software. Overall, they propose a solution to backlog problems during Scrum adoption. The study focuses on a development team, and applies interviews for information gathering, in addition, it uses notes and project management tools for backlog monitoring.

Irum Inayat and Siti Salwah [16], propose a framework to study requirements- driven collaboration in distributed agile teams and determine the impact of their collaboration patterns during iteration, defining collaboration in terms of communication as information sharing among team members and awareness of each other's knowledge. The authors conducted two case studies on agile teams, whose information was collected through questionnaires, semi-structured interviews and observation. Furthermore, the authors conclude that the proposed framework may be useful for researching and improving collaboration in the future. Overall, the article provides valuable insight into collaboration in agile teams and how to improve it to achieve success in agile projects.

Batra, Weidong and Mingyu [17] explore the concept of collaboration in the context of agile software development. The authors define collaboration as an interactive process in which team members work together to achieve common goals and identify four key dimensions of collaboration in agile software development: communication, coordination, cooperation, and commitment. Each dimension is examined in detail, and factors that can affect collaboration in each area are highlighted. The authors also describe the benefits of collaboration in agile software development, including increased efficiency, improved product quality, and increased customer satisfaction. The authors note that there is little research examining the nature and dimensions of collaboration in the context of agile software development. Interview data collected from five software development outsourcing providers in China were used to develop this paper.

# 3 Qualitative Study on the collaborative aspects taken into account by development teams during Scrum adoption

In many organizations, drawbacks have been found when adopting Scrum as a framework in their projects [4], these are related to factors associated with human behavior such as culture, organizational, interaction, companionship, communication, etc [10]. Next, the main problems and situations that arise during the adoption of Scrum are consolidated according to the empirical perspective of work team leaders. These problems will make it possible to identify the collaborative aspects that the team recognizes and which of them represent weaknesses in both the collaborative factors and the methodology.

## 3.1 Design

**Research question:** What are the collaborative aspects that software companies identify during Scrum adoption and how well do they cover collaboration-related features?
## Persons

The interviews are focused on systems engineers or similar, development team leaders in the context of the agile Scrum methodology in its adoption phase corresponding to small software development companies in the department of Cauca, Colombia.

At the time of carrying out this study, it was found that in the department of Cauca there are 95 software development companies, 36 of them are small software development companies, when contacting these companies, it was possible to determine that only 7 have equipment that is in process. Of Scrum adoption, of which 2 of them are in training and stated that they have no experience to report, for which only 5 companies can be studied. However, only 4 companies were interested in participating in this study and sharing their experience in adopting Scrum [18].

<table><caption>Table 1: Software development companies in the department of Cauca</caption><tr><td>Software development companies</td><td>95</td></tr><tr><td>Small software development companies</td><td>36</td></tr><tr><td>Small software development companies with Scrum adopter teams</td><td>7</td></tr><tr><td>Small software development companies with Scrum adopter teams with experience to report</td><td>5</td></tr></table>

## 3.2 Data collection method

The method of data collection in this study was semi-structured interview. Semi-structured interviews are an intermediate approach between standardized, mostly closed-ended surveys of individuals and free-participation sessions, with groups, are the semi-structured interviews [19].

The semi-structured interview is conducted conversationally with one respondent at a time, employing a combination of closed-ended and open-ended questions, often accompanied by backward follow-up questions (why and how). The dialogue can zigzag around agenda items, rather than rigidly adhering to literal questions as in a standardized survey, and can delve into entirely unanticipated issues. Semi-structured interviews are relaxed, engaging and, being face-to-face, can be longer than telephone surveys, although they last as long as focus groups. One hour is considered a reasonable maximum length for a structured interview to minimize fatigue for both inter-viewer and interviewee.

The practical steps for designing and conducting semi-structured interviews are: selecting and recruiting respondents, drafting the questions and the interview guide, applying the recommended techniques for this type of interview, and analyzing the information collected.

## Questions

The questionnaire of this semi-structured interview was applied to two experts who participated as judges in the content validation and presented their opinion, which allowed refining the questions in order to obtain the most relevant information for this study. The interview consisted of 22 questions, divided into four categories: Scrum (3 questions), interaction (6 questions), communication (5 questions) and awareness (8 questions).
## Persons

The interviews are focused on systems engineers or similar, development team leaders in the context of the agile Scrum methodology in its adoption phase corresponding to small software development companies in the department of Cauca, Colombia.

At the time of carrying out this study, it was found that in the department of Cauca there are 95 software development companies, 36 of them are small software development companies, when contacting these companies, it was possible to determine that only 7 have equipment that is in process. Of Scrum adoption, of which 2 of them are in training and stated that they have no experience to report, for which only 5 companies can be studied. However, only 4 companies were interested in participating in this study and sharing their experience in adopting Scrum [18].

<table><caption>Table 1: Software development companies in the department of Cauca</caption><tr><td>Software development companies</td><td>95</td></tr><tr><td>Small software development companies</td><td>36</td></tr><tr><td>Small software development companies with Scrum adopter teams</td><td>7</td></tr><tr><td>Small software development companies with Scrum adopter teams with experience to report</td><td>5</td></tr></table>

## 3.2 Data collection method

The method of data collection in this study was semi-structured interview. Semi-structured interviews are an intermediate approach between standardized, mostly closed-ended surveys of individuals and free-participation sessions, with groups, are the semi-structured interviews [19].

The semi-structured interview is conducted conversationally with one respondent at a time, employing a combination of closed-ended and open-ended questions, often accompanied by backward follow-up questions (why and how). The dialogue can zigzag around agenda items, rather than rigidly adhering to literal questions as in a standardized survey, and can delve into entirely unanticipated issues. Semi-structured interviews are relaxed, engaging and, being face-to-face, can be longer than telephone surveys, although they last as long as focus groups. One hour is considered a reasonable maximum length for a structured interview to minimize fatigue for both inter-viewer and interviewee.

The practical steps for designing and conducting semi-structured interviews are: selecting and recruiting respondents, drafting the questions and the interview guide, applying the recommended techniques for this type of interview, and analyzing the information collected.

## Questions

The questionnaire of this semi-structured interview was applied to two experts who participated as judges in the content validation and presented their opinion, which allowed refining the questions in order to obtain the most relevant information for this study. The interview consisted of 22 questions, divided into four categories: Scrum (3 questions), interaction (6 questions), communication (5 questions) and awareness (8 questions).
<table><tr><td>S</td><td><ol><li>How long have you been using the Scrum agile methodology?</li><li>What were the main problem(s) you encountered during the adoption of Scrum?</li><li>What problems do you see persisting from adoption to the present?</li></ol></td></tr><tr><td>Interaction</td><td><ol><li>Could you describe how the team carries out its daily activities?</li><li>Could you describe how you conduct the meetings?</li><li>What benefits do you find in the way the activities are being developed?</li><li>Could you tell us about the problems related to the interaction among the participants during the development of the activities? What do you think are the causes?</li><li>Could you please detail the procedure to follow when encountering and reporting a problem?</li><li>On a scale of 1-5 with 1 being very little and 5 being very much, how do you consider the interaction between the team participants?</li></ol></td></tr><tr><td>Communicatio</td><td><ol><li>Which digital channels and media do you use for communication? Which are the most indispensable?</li><li>What benefits do you find in the way your team's communications are going? What are its strengths?</li><li>What do you consider to be the most frequent problems during communication between participants?</li><li>What are the most common communication problems during meetings? What do you think are the causes?</li><li>On a scale of 1-5 with 1 being very little and 5 being very much, how do you consider the team's communication to be? Why?</li></ol></td></tr></table>

<table><tr><td>Awareness</td><td><ol><li>How does the team achieve a shared and ongoing understanding of the problem, the product and progress of the project for the entire team?</li><li>How do you know at this point what the status of the project is and what issue each team member is currently resolving?</li><li>What are your responsibilities and those of your colleagues in software projects?</li><li>To what extent do you feel responsible for the success or failure of the product? Why?</li><li>Do you consider that each team member is responsible for the success or failure of the product? Why?</li><li>On a scale of 1-5 with 1 being very little and 5 being very much, how do you consider your ongoing knowledge of the product's state of progress and the current tasks that team members are addressing?</li><li>Could you describe problems related to unfamiliarity with aspects related to the product, the project or the work of the team members?</li><li>Could you describe some strategies for solving the problems identified in your work team during this interview?</li></ol></td></tr></table>
<table><tr><td>S</td><td><ol><li>How long have you been using the Scrum agile methodology?</li><li>What were the main problem(s) you encountered during the adoption of Scrum?</li><li>What problems do you see persisting from adoption to the present?</li></ol></td></tr><tr><td>Interaction</td><td><ol><li>Could you describe how the team carries out its daily activities?</li><li>Could you describe how you conduct the meetings?</li><li>What benefits do you find in the way the activities are being developed?</li><li>Could you tell us about the problems related to the interaction among the participants during the development of the activities? What do you think are the causes?</li><li>Could you please detail the procedure to follow when encountering and reporting a problem?</li><li>On a scale of 1-5 with 1 being very little and 5 being very much, how do you consider the interaction between the team participants?</li></ol></td></tr><tr><td>Communicatio</td><td><ol><li>Which digital channels and media do you use for communication? Which are the most indispensable?</li><li>What benefits do you find in the way your team's communications are going? What are its strengths?</li><li>What do you consider to be the most frequent problems during communication between participants?</li><li>What are the most common communication problems during meetings? What do you think are the causes?</li><li>On a scale of 1-5 with 1 being very little and 5 being very much, how do you consider the team's communication to be? Why?</li></ol></td></tr></table>

<table><tr><td>Awareness</td><td><ol><li>How does the team achieve a shared and ongoing understanding of the problem, the product and progress of the project for the entire team?</li><li>How do you know at this point what the status of the project is and what issue each team member is currently resolving?</li><li>What are your responsibilities and those of your colleagues in software projects?</li><li>To what extent do you feel responsible for the success or failure of the product? Why?</li><li>Do you consider that each team member is responsible for the success or failure of the product? Why?</li><li>On a scale of 1-5 with 1 being very little and 5 being very much, how do you consider your ongoing knowledge of the product's state of progress and the current tasks that team members are addressing?</li><li>Could you describe problems related to unfamiliarity with aspects related to the product, the project or the work of the team members?</li><li>Could you describe some strategies for solving the problems identified in your work team during this interview?</li></ol></td></tr></table>
## Participants

The participants were four leaders of development teams belonging to small software development companies in the department of Cauca (Colombia), with ages between 36 - 51 years old, who voluntarily agreed to participate in the interview to deepen the collaborative aspects of Scrum during its adoption phase.

Regarding the gender of the participants, it can be highlighted that despite the fact that the study included a female participant, said participant is the leader of a larger team (15 people) and tends to behave as two teams (8 and 7 people).

<table><caption>Table 1: Participant information</caption><tr><td rowspan="4">Leader 1</td><td>Age</td><td>38</td></tr><tr><td>Genre</td><td>Male</td></tr><tr><td>Years of experience</td><td>10</td></tr><tr><td>Equipment size</td><td>9 people</td></tr><tr><td rowspan="4">Leader 2</td><td>Age</td><td>51</td></tr><tr><td>Genre</td><td>Male</td></tr><tr><td>Years of experience</td><td>More than 20</td></tr><tr><td>Equipment size</td><td>4 persons</td></tr><tr><td rowspan="4">Leader 3</td><td>Age</td><td>45</td></tr><tr><td>Genre</td><td>Male</td></tr><tr><td>Years of experience</td><td>13</td></tr><tr><td>Equipment size</td><td>7 people</td></tr></table>

<table><tr><td rowspan="4">Leader 4</td><td>Age</td><td>36</td></tr><tr><td>Genre</td><td>Female</td></tr><tr><td>Years of experience</td><td>7</td></tr><tr><td>Equipment size</td><td>15 people: Team divided into two, 8 - 7 people</td></tr></table>

## 3.3 Results and data analysis

The WEFT QDA software tool [20], a qualitative research tool used for the analysis of textual data such as interview transcripts, documents and field notes, was used for the analysis of the interviews. This tool is free to use and has a public domain license and is available for Windows and Linux.

This tool allows: 1) to save the data in an organized way based on categories defined by the researcher; 2) to search and classify the data (interview transcription) in analytical categories established by the researcher; 3) to establish relationships from the data through searches, 4) to visualize the searches in the form of texts or double-entry tables [19]. Once the information from the interviews was integrated into the tool, 4 categories of analysis were generated (Interaction, Communication, Awareness and Scrum) that generate a linearity between the objectives of this article and the analysis of results.
## Participants

The participants were four leaders of development teams belonging to small software development companies in the department of Cauca (Colombia), with ages between 36 - 51 years old, who voluntarily agreed to participate in the interview to deepen the collaborative aspects of Scrum during its adoption phase.

Regarding the gender of the participants, it can be highlighted that despite the fact that the study included a female participant, said participant is the leader of a larger team (15 people) and tends to behave as two teams (8 and 7 people).

<table><caption>Table 1: Participant information</caption><tr><td rowspan="4">Leader 1</td><td>Age</td><td>38</td></tr><tr><td>Genre</td><td>Male</td></tr><tr><td>Years of experience</td><td>10</td></tr><tr><td>Equipment size</td><td>9 people</td></tr><tr><td rowspan="4">Leader 2</td><td>Age</td><td>51</td></tr><tr><td>Genre</td><td>Male</td></tr><tr><td>Years of experience</td><td>More than 20</td></tr><tr><td>Equipment size</td><td>4 persons</td></tr><tr><td rowspan="4">Leader 3</td><td>Age</td><td>45</td></tr><tr><td>Genre</td><td>Male</td></tr><tr><td>Years of experience</td><td>13</td></tr><tr><td>Equipment size</td><td>7 people</td></tr></table>

<table><tr><td rowspan="4">Leader 4</td><td>Age</td><td>36</td></tr><tr><td>Genre</td><td>Female</td></tr><tr><td>Years of experience</td><td>7</td></tr><tr><td>Equipment size</td><td>15 people: Team divided into two, 8 - 7 people</td></tr></table>

## 3.3 Results and data analysis

The WEFT QDA software tool [20], a qualitative research tool used for the analysis of textual data such as interview transcripts, documents and field notes, was used for the analysis of the interviews. This tool is free to use and has a public domain license and is available for Windows and Linux.

This tool allows: 1) to save the data in an organized way based on categories defined by the researcher; 2) to search and classify the data (interview transcription) in analytical categories established by the researcher; 3) to establish relationships from the data through searches, 4) to visualize the searches in the form of texts or double-entry tables [19]. Once the information from the interviews was integrated into the tool, 4 categories of analysis were generated (Interaction, Communication, Awareness and Scrum) that generate a linearity between the objectives of this article and the analysis of results.
The WEFT QDA tool classified text fragments into 4 categories:

- Interaction: Aspects related to interaction in the work team are addressed and analyzed, either with the customer or among members of the same team from the Scrum perspective.

- Communication: The tools, techniques and/or communication channels used by the work team to have a constant communication among them from the Scrum perspective are analyzed.

- Awareness: Aspects related to project awareness, roles and/or responsibilities within the project are addressed and analyzed from a Scrum perspective.

- Scrum: It deals with the Scrum methodology that could not be included in any of the previous categories.

The first three categories represent Collaboration, since, as mentioned above, they are necessary for an activity to be collaborative. This classification presented the following results: **Table 2:**
*Text fragments by category*

<table><thead><tr><td>Category</td><td>Number of text fragments</td></tr></thead><tbody><tr><td>Interaction</td><td>19</td></tr><tr><td>Communication</td><td>40</td></tr><tr><td>Awareness</td><td>66</td></tr><tr><td>Scrum</td><td>13</td></tr><tr><td>Total</td><td>138</td></tr></tbody></table>

As a result of the interview, a list of activities was identified and grouped by frequency, i.e., how many teams coincided in mentioning the activity (1, 2, 3 or 4), and the activities developed by the teams were associated to collaborative activities and events or Scrum elements in order to identify activities within the methodology where the problems specified by the participants may occur.

The number of activities obtained in each category and the number of activities by frequency are presented below.

<table><caption>**Table 3: Activities vs. Frequency Collaboration**</caption><thead><tr><td>Category</td><td>Number of activities</td><td>Frequency by activity</td></tr></thead><tbody><tr><td>Interaction</td><td>3</td><td>3 Activities with frequency 4</td></tr><tr><td>Communication</td><td>5</td><td>4 Activities with frequency 3<br>1 Activity with frequency 2</td></tr><tr><td>Awareness</td><td>6</td><td>3 Activities with frequency 4<br>2 Activities with frequency 3<br>1 Activity with frequency 1</td></tr></tbody></table>
The WEFT QDA tool classified text fragments into 4 categories:

- Interaction: Aspects related to interaction in the work team are addressed and analyzed, either with the customer or among members of the same team from the Scrum perspective.

- Communication: The tools, techniques and/or communication channels used by the work team to have a constant communication among them from the Scrum perspective are analyzed.

- Awareness: Aspects related to project awareness, roles and/or responsibilities within the project are addressed and analyzed from a Scrum perspective.

- Scrum: It deals with the Scrum methodology that could not be included in any of the previous categories.

The first three categories represent Collaboration, since, as mentioned above, they are necessary for an activity to be collaborative. This classification presented the following results: **Table 2:**
*Text fragments by category*

<table><thead><tr><td>Category</td><td>Number of text fragments</td></tr></thead><tbody><tr><td>Interaction</td><td>19</td></tr><tr><td>Communication</td><td>40</td></tr><tr><td>Awareness</td><td>66</td></tr><tr><td>Scrum</td><td>13</td></tr><tr><td>Total</td><td>138</td></tr></tbody></table>

As a result of the interview, a list of activities was identified and grouped by frequency, i.e., how many teams coincided in mentioning the activity (1, 2, 3 or 4), and the activities developed by the teams were associated to collaborative activities and events or Scrum elements in order to identify activities within the methodology where the problems specified by the participants may occur.

The number of activities obtained in each category and the number of activities by frequency are presented below.

<table><caption>**Table 3: Activities vs. Frequency Collaboration**</caption><thead><tr><td>Category</td><td>Number of activities</td><td>Frequency by activity</td></tr></thead><tbody><tr><td>Interaction</td><td>3</td><td>3 Activities with frequency 4</td></tr><tr><td>Communication</td><td>5</td><td>4 Activities with frequency 3<br>1 Activity with frequency 2</td></tr><tr><td>Awareness</td><td>6</td><td>3 Activities with frequency 4<br>2 Activities with frequency 3<br>1 Activity with frequency 1</td></tr></tbody></table>
<table><caption>**Table 4:** Activities vs. Scrum Frequency</caption><thead><tr><td>Category</td><td>Number of activities</td><td>Frequency by activity</td></tr></thead><tbody><tr><td>Interaction</td><td>1</td><td>1 Frequent activity 4</td></tr><tr><td>Communication</td><td>2</td><td>2 Activities with frequency 4</td></tr><tr><td>Awareness</td><td>5</td><td>2 Activities with frequency 4<br>3 Activities with frequency 2</td></tr></tbody></table>

The activities with the highest incidence (frequency 4) reveal potential problems or risk factors present during adoption that may occur frequently in Scrum adopting teams. On the other hand, activities with lower incidence (frequency 1) reveal less common problems or risk factors.

Participants explicitly identified some of the potential problems they encountered during Scrum adoption based on their experience. Most of these potential problems are associated with the person factor evidenced by culture, beliefs, language, personality, and attitude.

For this work, risk is defined as the different factors that affect the correct adoption of Scrum. The main risks identified in this study were found from the text fragments (explicit statements of the participants) and in the associated activities. Below is the list of risks:

- Individual work thinking: some individuals prefer to work alone or develop their activities without relating to the work team.

- Downplaying the purpose of each Scrum event (lack of awareness): They do not know the purpose of the events and how they impact the process.

- Lack of participation or absence during sessions: Some team members do not wish to participate during sessions so they avoid being present, do not pay attention and/or present little or no participation.

- The person factor can affect the adoption process: the process can be affected by a person's personality, character, customs, beliefs, etc.

- Absence of collective ownership of information: team members are unaware of the progress of the process and the activities carried out by other team members.

- Lack of effective communication: Communication through multiple messaging tools or channels can lead to loss of information or confusion.

- Lack of cooperation and constant communication with the client: The custom-er is taken into account only at the end of the process.

- Lack of discipline in daily meetings: Meetings are extended, the objective is not met, the progress of the process is not clear.

- Lack of constant customer participation: The customer loses or has no interest so does not get involved in the process.

- Lack of understanding of agile values: team members have different understanding of agile values.

- Lack of understanding of meeting objectives: team members do not have the same perception of the purpose of Scrum meetings.

## 4 Conclusions and future work

Scrum is a popular agile project management methodology used in software development and other complex projects. Although Scrum focuses on collaboration among team members, there are several collaboration issues that can arise. The semi-structured interviews conducted provide insight into the potential issues that Scrum adopter teams from small software development organizations face during their adoption process regarding collaboration.
<table><caption>**Table 4:** Activities vs. Scrum Frequency</caption><thead><tr><td>Category</td><td>Number of activities</td><td>Frequency by activity</td></tr></thead><tbody><tr><td>Interaction</td><td>1</td><td>1 Frequent activity 4</td></tr><tr><td>Communication</td><td>2</td><td>2 Activities with frequency 4</td></tr><tr><td>Awareness</td><td>5</td><td>2 Activities with frequency 4<br>3 Activities with frequency 2</td></tr></tbody></table>

The activities with the highest incidence (frequency 4) reveal potential problems or risk factors present during adoption that may occur frequently in Scrum adopting teams. On the other hand, activities with lower incidence (frequency 1) reveal less common problems or risk factors.

Participants explicitly identified some of the potential problems they encountered during Scrum adoption based on their experience. Most of these potential problems are associated with the person factor evidenced by culture, beliefs, language, personality, and attitude.

For this work, risk is defined as the different factors that affect the correct adoption of Scrum. The main risks identified in this study were found from the text fragments (explicit statements of the participants) and in the associated activities. Below is the list of risks:

- Individual work thinking: some individuals prefer to work alone or develop their activities without relating to the work team.

- Downplaying the purpose of each Scrum event (lack of awareness): They do not know the purpose of the events and how they impact the process.

- Lack of participation or absence during sessions: Some team members do not wish to participate during sessions so they avoid being present, do not pay attention and/or present little or no participation.

- The person factor can affect the adoption process: the process can be affected by a person's personality, character, customs, beliefs, etc.

- Absence of collective ownership of information: team members are unaware of the progress of the process and the activities carried out by other team members.

- Lack of effective communication: Communication through multiple messaging tools or channels can lead to loss of information or confusion.

- Lack of cooperation and constant communication with the client: The custom-er is taken into account only at the end of the process.

- Lack of discipline in daily meetings: Meetings are extended, the objective is not met, the progress of the process is not clear.

- Lack of constant customer participation: The customer loses or has no interest so does not get involved in the process.

- Lack of understanding of agile values: team members have different understanding of agile values.

- Lack of understanding of meeting objectives: team members do not have the same perception of the purpose of Scrum meetings.

## 4 Conclusions and future work

Scrum is a popular agile project management methodology used in software development and other complex projects. Although Scrum focuses on collaboration among team members, there are several collaboration issues that can arise. The semi-structured interviews conducted provide insight into the potential issues that Scrum adopter teams from small software development organizations face during their adoption process regarding collaboration.
- A person who wants to work individually, with little or no interaction with other team members, and who is reluctant to change this behavior can threaten the adoption of Scrum, since individual attitudes are detrimental to teamwork and project development.

- The use of several communication channels does not guarantee good communication and can lead to confusion or information not being taken into account in a timely manner. Tools such as Skype, google, even WhatsApp, allow constant communication between team members. However, these tools do not offer a guide to manage communications.

- Team members have different understandings of agile events and values, which hinders the participation of some team members and in turn creates an absence of a shared understanding of the problem, the product, and the progress of the project.

- Some teams incorporate artifacts from traditional methodologies that they con sider indispensable to the project, leading to an adaptation of these artifacts to the agile methodology. Teams are applying a modified adoption.

- The person factor, i.e., culture, beliefs, ethnicity, language, personality, attitude, etc. can affect the adoption process.

- Teams see the need for Scrum training of its members for a better adoption of the methodology. However, the adoption must be a voluntary and conscious decision to internalize not only the Scrum process and methodology, but also the agile values and principles, so that the team's thinking changes, and influence the change in the organizational culture.

In conclusion, collaboration issues in software development teams directly impact the Scrum adoption process, as they can cause team members to lose confidence in the Scrum process, which can make them reluctant to adopt the methodology in the future. In addition, they weaken one of the pillars of the methodology and hinder the adoption process, the identification of potential problems during the adoption process can be considered an alert that shallow adoption may result, although Scrum is adaptable, it requires commitment from all team members and a shared understanding of the process, so it is important to proactively address potential collaboration issues to ensure the successful adoption of Scrum.

As future work, it is planned to interview more software development companies adopting Scrum in order to identify more potential problems in a national and interna tional context. Based on the previously identified problems, a series of recommenda tions will be made to strengthen collaboration during the adoption of Scrum and a case study to validate these recommendations. This in order to provide tools to Scrum adopter teams to mitigate the potential problems reported in this work.
- A person who wants to work individually, with little or no interaction with other team members, and who is reluctant to change this behavior can threaten the adoption of Scrum, since individual attitudes are detrimental to teamwork and project development.

- The use of several communication channels does not guarantee good communication and can lead to confusion or information not being taken into account in a timely manner. Tools such as Skype, google, even WhatsApp, allow constant communication between team members. However, these tools do not offer a guide to manage communications.

- Team members have different understandings of agile events and values, which hinders the participation of some team members and in turn creates an absence of a shared understanding of the problem, the product, and the progress of the project.

- Some teams incorporate artifacts from traditional methodologies that they con sider indispensable to the project, leading to an adaptation of these artifacts to the agile methodology. Teams are applying a modified adoption.

- The person factor, i.e., culture, beliefs, ethnicity, language, personality, attitude, etc. can affect the adoption process.

- Teams see the need for Scrum training of its members for a better adoption of the methodology. However, the adoption must be a voluntary and conscious decision to internalize not only the Scrum process and methodology, but also the agile values and principles, so that the team's thinking changes, and influence the change in the organizational culture.

In conclusion, collaboration issues in software development teams directly impact the Scrum adoption process, as they can cause team members to lose confidence in the Scrum process, which can make them reluctant to adopt the methodology in the future. In addition, they weaken one of the pillars of the methodology and hinder the adoption process, the identification of potential problems during the adoption process can be considered an alert that shallow adoption may result, although Scrum is adaptable, it requires commitment from all team members and a shared understanding of the process, so it is important to proactively address potential collaboration issues to ensure the successful adoption of Scrum.

As future work, it is planned to interview more software development companies adopting Scrum in order to identify more potential problems in a national and interna tional context. Based on the previously identified problems, a series of recommenda tions will be made to strengthen collaboration during the adoption of Scrum and a case study to validate these recommendations. This in order to provide tools to Scrum adopter teams to mitigate the potential problems reported in this work.
References

1. Papadopoulos, G. Z.: Moving from Traditional to Agile Software Development Methodologies Also on Large, Distributed Projects. Procedia - Social and Behavioral Sciences, 175, 455-463. https://doi.org/10.1016/j.sbspro.2015.01.1223. (2015).

2. Rodríguez, C., & Dorado, R.: ¿Por qué implementar Scrum? Ontare, 3(1), 125-144. https://doi.org/10.21158/23823399.v3.n1.2015.1253. (2015).

3. Schwaber, K. SCRUM Development Process. En Springer eBooks (pp. 117-134). https://doi.org/10.1007/978-1-4471-0947-1_11. (1997).

4. González, J. J. M., Pardo, C., & Gómez, O. S.: Revisión sistemática acerca de la implementación de metodologías ágiles y otros modelos en micro, pequeñas y medianas empresas de software. Revista Tecnológica - ESPOL, 28(5). (2015).

5. VersionOne. VersionOne 10th Annual State of Agile Report, VersionOne, vol. 6, n° 2, pp. 2-8. (2006)

6. Ali, A., Rehman, M., & Anjum, M.: Framework for Applicability of Agile Scrum Methodology: A Perspective of Software Industry. International Journal of Advanced Computer Science and Applications, 8(9). https://doi.org/10.14569/ijacsa.2017.080932. (2017).

7. N. Khan, N. Ikram y S. Imtiaz.: SCRUM Adoption: A Solution to Backlog Problems. Fifth Asian Conference on Information Systems, At Krabi, Thailand. (2016)

8. J. López, R. Juárez, C. Huertas, S. Jiménez y C. Guerra.: Problems in the Adoption of Agile Scrum Methodologies: A Systematic Literature Review. 4th International Conference in Software Engineering Research and Innovation (CONISOFT), Puebla, México. (2016).

9. C. Collazos, S. Ochoa y J. Mendoza.: Collaborative evaluation as a mechanism for improving evaluation of classroom learning. Ingeniería e Investigación, vol. 27, n° 2, pp. 72-76. (2007).

10. Kanane, A. Challenges related to the adoption of Scrum. Case study of a financial IT company. UMEA University, Department of informatics. IT management master program, Umea, Suecia. (2014).

11. R. Owen Briggs, G. Kolfschoten, G.-J. De Vreede y D. L. Dean.: Defining Key Concepts for Collaboration Engineering. Americas Conference on Information Systems Proceedings, Acapulco, Mexico. (2006).

12. D. Mishra, A. Mishra y S. Ostrovska. Impact of physical ambiance on communication, col-laboration and coordination in agile software development: An empirical evaluation. In- formation and Software Technology, vol. 54, n° 10, p. 1067-1078. (2012).

13. S. Werner Knoll, M. Hörning y G. Horton.: Applying a ThinkLet and ThinXel based Group Process Modeling Language: A Prototype of a Universal Group Support System. deProceedings of the 42nd Hawaii International Conference on System Sciences, Hawaii. (2009).

14. C. Restrepo, L. Jiménez y J. A. Hurtado.: Integrating collaboration engineering with software process modeling: a visual approach. In Proceedings of the XVIII International Conference on Human Computer Interaction (pp. 1-2), Cancun, Mexico. (2017).

15. L. V. Araujo y A. N. Castrillón.: Una ruta de trabajo para la adopción de Scrum en pequeñas organizaciones en la industria del software. Universidad del Cauca, Popayán, Cauca. (2017).

16. I. Inayat y S. S. Salim.: A framework to study requirements-driven collaboration among agile teams: Findings from two case studies. Computers in Human Behavior, vol. 51, pp. 1367-1379. (2015).

17. Batra, Dinesh; XIA, Weidong; ZHANG, Mingyu. Collaboration in agile software development: Concept and dimensions. Communications of the Association for Information Systems, 2017, vol. 41, no 1, p. 20. (2017).

18. DANE, Geovisor Directorio de empresas 2023. http://www.pressure.to/qda/, last accessed 2023/05/27.

19. Laura Díaz-Bravo, Uri Torruco-García, Mildred Martínez-Hernández, Margarita Varela-Ruiz. La entrevista, recurso flexible y dinámico. Universidad Nacional Autónoma de México, México D.F., México. (2013).

20. University of Surrey, WEFT QDA. http://www.pressure.to/qda/, last accessed 2023/04/21.
References

1. Papadopoulos, G. Z.: Moving from Traditional to Agile Software Development Methodologies Also on Large, Distributed Projects. Procedia - Social and Behavioral Sciences, 175, 455-463. https://doi.org/10.1016/j.sbspro.2015.01.1223. (2015).

2. Rodríguez, C., & Dorado, R.: ¿Por qué implementar Scrum? Ontare, 3(1), 125-144. https://doi.org/10.21158/23823399.v3.n1.2015.1253. (2015).

3. Schwaber, K. SCRUM Development Process. En Springer eBooks (pp. 117-134). https://doi.org/10.1007/978-1-4471-0947-1_11. (1997).

4. González, J. J. M., Pardo, C., & Gómez, O. S.: Revisión sistemática acerca de la implementación de metodologías ágiles y otros modelos en micro, pequeñas y medianas empresas de software. Revista Tecnológica - ESPOL, 28(5). (2015).

5. VersionOne. VersionOne 10th Annual State of Agile Report, VersionOne, vol. 6, n° 2, pp. 2-8. (2006)

6. Ali, A., Rehman, M., & Anjum, M.: Framework for Applicability of Agile Scrum Methodology: A Perspective of Software Industry. International Journal of Advanced Computer Science and Applications, 8(9). https://doi.org/10.14569/ijacsa.2017.080932. (2017).

7. N. Khan, N. Ikram y S. Imtiaz.: SCRUM Adoption: A Solution to Backlog Problems. Fifth Asian Conference on Information Systems, At Krabi, Thailand. (2016)

8. J. López, R. Juárez, C. Huertas, S. Jiménez y C. Guerra.: Problems in the Adoption of Agile Scrum Methodologies: A Systematic Literature Review. 4th International Conference in Software Engineering Research and Innovation (CONISOFT), Puebla, México. (2016).

9. C. Collazos, S. Ochoa y J. Mendoza.: Collaborative evaluation as a mechanism for improving evaluation of classroom learning. Ingeniería e Investigación, vol. 27, n° 2, pp. 72-76. (2007).

10. Kanane, A. Challenges related to the adoption of Scrum. Case study of a financial IT company. UMEA University, Department of informatics. IT management master program, Umea, Suecia. (2014).

11. R. Owen Briggs, G. Kolfschoten, G.-J. De Vreede y D. L. Dean.: Defining Key Concepts for Collaboration Engineering. Americas Conference on Information Systems Proceedings, Acapulco, Mexico. (2006).

12. D. Mishra, A. Mishra y S. Ostrovska. Impact of physical ambiance on communication, col-laboration and coordination in agile software development: An empirical evaluation. In- formation and Software Technology, vol. 54, n° 10, p. 1067-1078. (2012).

13. S. Werner Knoll, M. Hörning y G. Horton.: Applying a ThinkLet and ThinXel based Group Process Modeling Language: A Prototype of a Universal Group Support System. deProceedings of the 42nd Hawaii International Conference on System Sciences, Hawaii. (2009).

14. C. Restrepo, L. Jiménez y J. A. Hurtado.: Integrating collaboration engineering with software process modeling: a visual approach. In Proceedings of the XVIII International Conference on Human Computer Interaction (pp. 1-2), Cancun, Mexico. (2017).

15. L. V. Araujo y A. N. Castrillón.: Una ruta de trabajo para la adopción de Scrum en pequeñas organizaciones en la industria del software. Universidad del Cauca, Popayán, Cauca. (2017).

16. I. Inayat y S. S. Salim.: A framework to study requirements-driven collaboration among agile teams: Findings from two case studies. Computers in Human Behavior, vol. 51, pp. 1367-1379. (2015).

17. Batra, Dinesh; XIA, Weidong; ZHANG, Mingyu. Collaboration in agile software development: Concept and dimensions. Communications of the Association for Information Systems, 2017, vol. 41, no 1, p. 20. (2017).

18. DANE, Geovisor Directorio de empresas 2023. http://www.pressure.to/qda/, last accessed 2023/05/27.

19. Laura Díaz-Bravo, Uri Torruco-García, Mildred Martínez-Hernández, Margarita Varela-Ruiz. La entrevista, recurso flexible y dinámico. Universidad Nacional Autónoma de México, México D.F., México. (2013).

20. University of Surrey, WEFT QDA. http://www.pressure.to/qda/, last accessed 2023/04/21.
# A literature review to enabling strategic decision support systems for crisismanagement

Elandaloussi Sidahmed¹ and Zaraté Pascale ¹

¹ IRIT / Toulouse University
2 Rue du Doyen Gabriel Marty, 31042 Toulouse Cedex 9, Francesid elandaloussi@irit.fr
Pascale.Zarate@irit.fr, web-page: https://www.irit.fr/~Pascale.Zarate

**Abstract.** This study aims to draw the main concepts in the literature concerning strategic decision support systems (SDSS) which have become widely incorporated in many specialized areas like logistics, medical, transport, trade, education...etc. However, this paper reports a literature review on decision support systems (DSS) for strategic crisis management. The paper deals with SDSS technologies to benefit from their advantages and integrates them into crisis management tasks. Moreover, managing a crisis effectively is an important component of deciding the level of crisis responsibility. In this paper we define a methodology to analyse a literature review. This analysis allows us to define four criteria to distinguish which SDSS is better.

**Keywords:** Strategic Decision Support Systems, Crisis Management, Strategic planning, Strategic management.

## 1 Introduction

Crisis management is described as the process by which different organizations and firms deal with a sudden emergency situation. The covid-19 crisis that began in early 2020 is a better example for now of crisis management. It has caused the most sudden and deepest global recession since the Second World War. Since this period, there exists a growing body of literature on crisis management. For instance, [1] presents a report that defines a thorough comparison and in-depth analysis of the emergency and recovery plans announced by European countries.

Our methodology is composed of two steps: first defining the research question consist of analysing the literature review for strategic decision support systems before classifying them and determining which SDSS will be better in similar situations. Although, strategic DSS is based on many DSS features. Some researchers have adopted a decision support system in their own activities in order to improve some technical aspects. However, other surveys have developed Strategic decision Support Systems. Despite the SDSS deployment complexity, previous research in several fields highlight the benefits of using SDSS such as industrial [2], supply chain management [3], medical domain [4], logistics management [5,6] especially in transport [7], crisis management [8]. The survey [9] provides some preliminary empirical evidence on what the most promising crisis strategies are to manage the COVID-19 crisis.

This article is divided into four main parts. The first part is devoted to discussing a comprehensive methodology for literature review. The second part is dedicated to outline a brief description of the most important studies in SDSS technologies. The third part is dedicated to analyze and classify the selected literature. The last part summarizes the paper and offers further insights for future studies.
# A literature review to enabling strategic decision support systems for crisismanagement

Elandaloussi Sidahmed¹ and Zaraté Pascale ¹

¹ IRIT / Toulouse University
2 Rue du Doyen Gabriel Marty, 31042 Toulouse Cedex 9, Francesid elandaloussi@irit.fr
Pascale.Zarate@irit.fr, web-page: https://www.irit.fr/~Pascale.Zarate

**Abstract.** This study aims to draw the main concepts in the literature concerning strategic decision support systems (SDSS) which have become widely incorporated in many specialized areas like logistics, medical, transport, trade, education...etc. However, this paper reports a literature review on decision support systems (DSS) for strategic crisis management. The paper deals with SDSS technologies to benefit from their advantages and integrates them into crisis management tasks. Moreover, managing a crisis effectively is an important component of deciding the level of crisis responsibility. In this paper we define a methodology to analyse a literature review. This analysis allows us to define four criteria to distinguish which SDSS is better.

**Keywords:** Strategic Decision Support Systems, Crisis Management, Strategic planning, Strategic management.

## 1 Introduction

Crisis management is described as the process by which different organizations and firms deal with a sudden emergency situation. The covid-19 crisis that began in early 2020 is a better example for now of crisis management. It has caused the most sudden and deepest global recession since the Second World War. Since this period, there exists a growing body of literature on crisis management. For instance, [1] presents a report that defines a thorough comparison and in-depth analysis of the emergency and recovery plans announced by European countries.

Our methodology is composed of two steps: first defining the research question consist of analysing the literature review for strategic decision support systems before classifying them and determining which SDSS will be better in similar situations. Although, strategic DSS is based on many DSS features. Some researchers have adopted a decision support system in their own activities in order to improve some technical aspects. However, other surveys have developed Strategic decision Support Systems. Despite the SDSS deployment complexity, previous research in several fields highlight the benefits of using SDSS such as industrial [2], supply chain management [3], medical domain [4], logistics management [5,6] especially in transport [7], crisis management [8]. The survey [9] provides some preliminary empirical evidence on what the most promising crisis strategies are to manage the COVID-19 crisis.

This article is divided into four main parts. The first part is devoted to discussing a comprehensive methodology for literature review. The second part is dedicated to outline a brief description of the most important studies in SDSS technologies. The third part is dedicated to analyze and classify the selected literature. The last part summarizes the paper and offers further insights for future studies.
## 2 Research Methodology

In this section we describe the research methodology adopted to collect conferences and journals articles that includes Strategic Decision support systems as keywords. However, we have used an advanced search for articles related to SDSS that appeared only in these 4 data sources: Web of knowledge, Science direct, Scopus and Google scholar by using the following keywords as important search criteria : "SDSS", "Strategic Decision Support Systems", "Crisis management", "SDSS architecture", "Strategic Management models", "Strategic planning models".

After that, we have filtered the papers to retain only those in English related to the SDSSs fields. Then, we scanned titles and abstract for each selected paper. Finally, we reviewed their citations and references.

Figure 1 shows an overview of the used searching and selecting papers methodology to demonstrate the various search efforts that are carried out. Furthermore, some findings papers are presented in this present study and the rest in an extension paper.

<figure><img src="image_38.png" /><figcaption>Fig. 1. Searching and selecting papers methodology.</figcaption></figure>
## 2 Research Methodology

In this section we describe the research methodology adopted to collect conferences and journals articles that includes Strategic Decision support systems as keywords. However, we have used an advanced search for articles related to SDSS that appeared only in these 4 data sources: Web of knowledge, Science direct, Scopus and Google scholar by using the following keywords as important search criteria : "SDSS", "Strategic Decision Support Systems", "Crisis management", "SDSS architecture", "Strategic Management models", "Strategic planning models".

After that, we have filtered the papers to retain only those in English related to the SDSSs fields. Then, we scanned titles and abstract for each selected paper. Finally, we reviewed their citations and references.

Figure 1 shows an overview of the used searching and selecting papers methodology to demonstrate the various search efforts that are carried out. Furthermore, some findings papers are presented in this present study and the rest in an extension paper.

<figure><img src="image_52.png" /><figcaption>Fig. 1. Searching and selecting papers methodology.</figcaption></figure>
## 3 Strategic Decision Support Systems

Decision support systems (DSS) are an important application of management information systems which apply different decision rules and models. [10] Consider a DSS as “an interactive and adaptable Computer Based Information System which helps non-organized management problems”.

Strategic DSS provide more explanatory information than DSS by explaining concepts and simulating thinking. According to [11] strategy has also been viewed as consisting of three processes: strategic planning [12], strategic thinking [13], and opportunistic decision making [14].

On the one hand, the technical aspects of DSS are widely considered by several surveys but strategic ones are very neglected. In fact, the combination of strategic actions with DSS is very promising and their literature is large and varies according to the SDSSs functionality. Although, without strategic methods the decision falters to achieve organizational goals.

On the other hand, previous research deals with the benefits of strategic DSS in many specialized areas (supply chain and logistics [15], the agrifood industry [16] ...). For instance, in order to achieve effective decision making in Logistics [15] proposes a strategic DSS framework which combines both the strategic management process and the Strategic Information Systems Planning (SISP) process. Another area of logistics where strategic DSS are used to handle storage systems based on the estimation of parameters is costs for racks and storage equipment [17]. Regarding [15] the existing strategic actions included in DSS are summarized in **Table 1**.

<table><caption>**Table 1.** The existing strategic actions including in DSS [15].</caption><thead><tr><td>Strategic Actions including in DSS</td><td>References</td></tr></thead><tbody><tr><td>Identification of environmental trends, internal trends and performance trends</td><td>[18]</td></tr><tr><td>Planning responses to the issues</td><td></td></tr><tr><td>Assessing the impact and urgency of the issues, and prioritizing the issues</td><td></td></tr><tr><td>Evaluation</td><td>[19]</td></tr><tr><td>Culture Analysis</td><td></td></tr><tr><td>Environment Analysis</td><td></td></tr><tr><td>SWOT Analysis</td><td></td></tr><tr><td>Strategy Operating Subsystem</td><td>[20]</td></tr><tr><td>Goal-setting Subsystem</td><td></td></tr><tr><td>Environmental Analysis Subsystem</td><td></td></tr></tbody></table>

## 4 Discussion

After examination of the different selected SDSS that have been developed we could use a set of criteria to classify these systems: Single user based SDSS, Group user based SDSS, Methodology based SDSS and Software based SDSS.
# 3 Strategic Decision Support Systems

Decision support systems (DSS) are an important application of management information systems which apply different decision rules and models. [10] Consider a DSS as "an interactive and adaptable Computer Based Information System which helps non-organized management problems".

Strategic DSS provide more explanatory information than DSS by explaining concepts and simulating thinking. According to [11] strategy has also been viewed as consisting of three processes: strategic planning [12], strategic thinking [13], and opportunistic decision making [14].

On the one hand, the technical aspects of DSS are widely considered by several surveys but strategic ones are very neglected. In fact, the combination of strategic actions with DSS is very promising and their literature is large and varies according to the SDSSs functionality. Although, without strategic methods the decision falters to achieve organizational goals.

On the other hand, previous research deals with the benefits of strategic DSS in many specialized areas (supply chain and logistics [15], the agrifood industry [16] ...). For instance, in order to achieve effective decision making in Logistics [15] proposes a strategic DSS framework which combines both the strategic management process and the Strategic Information Systems Planning (SISP) process. Another area of logistics where strategic DSS are used to handle storage systems based on the estimation of parameters is costs for racks and storage equipment [17]. Regarding [15] the existing strategic actions included in DSS are summarized in Table 1.

<table><caption>Table 1. The existing strategic actions including in DSS [15].</caption><thead><tr><td>Strategic Actions including in DSS</td><td>References</td></tr></thead><tbody><tr><td>Identification of environmental trends, internal trends and performance trends</td><td>[18]</td></tr><tr><td>Planning responses to the issues</td><td></td></tr><tr><td>Assessing the impact and urgency of the issues, and prioritizing the issues</td><td></td></tr><tr><td>Evaluation</td><td>[19]</td></tr><tr><td>Culture Analysis</td><td></td></tr><tr><td>Environment Analysis</td><td></td></tr><tr><td>SWOT Analysis</td><td></td></tr><tr><td>Strategy Operating Subsystem</td><td>[20]</td></tr><tr><td>Goal-setting Subsystem</td><td></td></tr><tr><td>Environmental Analysis Subsystem</td><td></td></tr></tbody></table>

# 4 Discussion

After examination of the different selected SDSS that have been developed we could use a set of criteria to classify these systems: Single user based SDSS, Group user based SDSS, Methodology based SDSS and Software based SDSS.
SDSS. Among the selected paper in SDSS some of them are dealt in this survey and classified according to these criteria as below:

<table><caption>**Table. 2.** Surveys classification according to the generated criteria.</caption><thead><tr><td>Simple user based SDSS</td><td>Group user based SDSS</td><td>Methodology based SDSS</td><td>Software based SDSS</td></tr></thead><tbody><tr><td>[21]</td><td>[19]</td><td>[2]</td><td>[22]</td></tr><tr><td>[23]</td><td>[15]</td><td>[24]</td><td>[11]</td></tr><tr><td>[26]</td><td>[20]</td><td>[28]</td><td>[29]</td></tr><tr><td>[30]</td><td>[31]</td><td>[15]</td><td>[19]</td></tr><tr><td>[32]</td><td>[33]</td><td>[34]</td><td>[20]</td></tr><tr><td>-</td><td>[35]</td><td>[17]</td><td>[31]</td></tr><tr><td>-</td><td>[36]</td><td>[36]</td><td>[33]</td></tr></tbody></table>

<table><tr><td>-</td><td>-</td><td>[37]</td><td>[26]</td></tr><tr><td>-</td><td>-</td><td>[10]</td><td>[38]</td></tr><tr><td>-</td><td>-</td><td>[39]</td><td>-</td></tr><tr><td>-</td><td>-</td><td>[15]</td><td>-</td></tr><tr><td>-</td><td>-</td><td>[20]</td><td>-</td></tr></table>

Based on this classification (See Table2), we can assume that SDSS methodology oriented are very largely covered. Then several SDSS software are designed and finally considering the low number of studies for Single decision makers, we can assume that SDSS is more a matter of Group of decision Makers rather than single Decision Maker. Furthermore, to make it very simple the application of all works indicated in this table will be described in detail in an extended study.

## 5 Conclusion

In this study, the existing literature on SDSS is reviewed and their comprehensive assessments are provided. Thus, managing a crisis efficiently is an important component for controlling and promptly preventing its negative consequences. In fact, to classify the selected literature four criteria have been introduced: Single user based SDSS, Group user based SDSS, Methodology based SDSS, Software based SDSS.

Based on this analysis, we can see that Strategic DSS is more a matter of group of decision Makers and that they are well supported more by methodologies rather than techniques. Otherwise, as future work, an extended paper of this work will include a detailed analysis of covid-19 pandemic management, will explain the different architecture of defined strategic DSS and we will demonstrate which SDSS is better to deal with each crisis.

## References

1. Aussilloux, V., Mavridis, D., Baïz, A., Garrigue, M.: The effects of the covid-19 crisis on productivity and competitiveness. (2021).

2. Agostino, B., Massei, M., Sinelshnkov, K.: Enabling Strategic Decisions for the Industry of Tomorrow. Volume 42, Pages 548-553,doi.org/10.1016/j.promfg (2020).

3. Ye, F., Liu, K., Li, K., Lai, K., Zhan, Y., Kumar, A.: Digital supply chain management in the COVID-19 crisis: An asset orchestration perspective. Int. J. Production Economics 245 108396, (2022).

4. Shahparvari, S., Hassanizadeh, B., Mohammadi, A., Kiani, B., Lau, K., Chhetri, P., Abbasi, B.: A decision support system for prioritised COVID-19 two-dosage vaccination allocation and distribution. Volume 159,102598, doi.org/10.1016/j.tre.2021.102598, (2022).

5. Kamariotou, M., Kitsios, F., Michael, A., Manthou, V.: Strategic Decision Support Systems for Logistics in the Agrifood Industry, Proceedings of 8th International Conference on Information and Communication Technologies in Agriculture, Chania, Greece (2017).

6. Henrik N., Thompson, A., Lindahl, P., Broman, G.: Introducing strategic decision support systems for sustainable product-service innovation across value chains, Proceedings of Sustainable Innovation, Malmö, Sweden, id: diva2:889466(2008)

7. Barfod, M., Salling, K.: A new composite decision support framework for strategic and sustainable
SDSS. Among the selected paper in SDSS some of them are dealt in this survey and classified according to these criteria as below:

<table><caption>**Table. 2.** Surveys classification according to the generated criteria.</caption><thead><tr><td>Simple user based SDSS</td><td>Group user based SDSS</td><td>Methodology based SDSS</td><td>Software based SDSS</td></tr></thead><tbody><tr><td>[21]</td><td>[19]</td><td>[2]</td><td>[22]</td></tr><tr><td>[23]</td><td>[15]</td><td>[24]</td><td>[11]</td></tr><tr><td>[26]</td><td>[20]</td><td>[28]</td><td>[29]</td></tr><tr><td>[30]</td><td>[31]</td><td>[15]</td><td>[19]</td></tr><tr><td>[32]</td><td>[33]</td><td>[34]</td><td>[20]</td></tr><tr><td>-</td><td>[35]</td><td>[17]</td><td>[31]</td></tr><tr><td>-</td><td>[36]</td><td>[36]</td><td>[33]</td></tr></tbody></table>

<table><tr><td>-</td><td>-</td><td>[37]</td><td>[26]</td></tr><tr><td>-</td><td>-</td><td>[10]</td><td>[38]</td></tr><tr><td>-</td><td>-</td><td>[39]</td><td>-</td></tr><tr><td>-</td><td>-</td><td>[15]</td><td>-</td></tr><tr><td>-</td><td>-</td><td>[20]</td><td>-</td></tr></table>

Based on this classification (See Table2), we can assume that SDSS methodology oriented are very largely covered. Then several SDSS software are designed and finally considering the low number of studies for Single decision makers, we can assume that SDSS is more a matter of Group of decision Makers rather than single Decision Maker. Furthermore, to make it very simple the application of all works indicated in this table will be described in detail in an extended study.

## 5 Conclusion

In this study, the existing literature on SDSS is reviewed and their comprehensive assessments are provided. Thus, managing a crisis efficiently is an important component for controlling and promptly preventing its negative consequences. In fact, to classify the selected literature four criteria have been introduced: Single user based SDSS, Group user based SDSS, Methodology based SDSS, Software based SDSS.

Based on this analysis, we can see that Strategic DSS is more a matter of group of decision Makers and that they are well supported more by methodologies rather than techniques. Otherwise, as future work, an extended paper of this work will include a detailed analysis of covid-19 pandemic management, will explain the different architecture of defined strategic DSS and we will demonstrate which SDSS is better to deal with each crisis.

## References

1. Aussilloux, V., Mavridis, D., Baïz, A., Garrigue, M.: The effects of the covid-19 crisis on productivity and competitiveness. (2021).

2. Agostino, B., Massei, M., Sinelshnkov, K.: Enabling Strategic Decisions for the Industry of Tomorrow. Volume 42, Pages 548-553,doi.org/10.1016/j.promfg (2020).

3. Ye, F., Liu, K., Li, K., Lai, K., Zhan, Y., Kumar, A.: Digital supply chain management in the COVID-19 crisis: An asset orchestration perspective. Int. J. Production Economics 245 108396, (2022).

4. Shahparvari, S., Hassanizadeh, B., Mohammadi, A., Kiani, B., Lau, K., Chhetri, P., Abbasi, B.: A decision support system for prioritised COVID-19 two-dosage vaccination allocation and distribution. Volume 159,102598, doi.org/10.1016/j.tre.2021.102598, (2022).

5. Kamariotou, M., Kitsios, F., Michael, A., Manthou, V.: Strategic Decision Support Systems for Logistics in the Agrifood Industry, Proceedings of 8th International Conference on Information and Communication Technologies in Agriculture, Chania, Greece (2017).

6. Henrik N., Thompson, A., Lindahl, P., Broman, G.: Introducing strategic decision support systems for sustainable product-service innovation across value chains, Proceedings of Sustainable Innovation, Malmö, Sweden, id: diva2:889466(2008)

7. Barfod, M., Salling, K.: A new composite decision support framework for strategic and sustainable
transport appraisals, Volume 72, Pages 1-15, (2015)

8. Jaziri, R., Miralama, S.: The impact of crisis and disasters risk management in COVID-19 times: Insights and lessons learned from Saudi Arabia, Medicine and Public Health 18, 100705, (2021).

9. Klyver, K., Nielsen, S.: Which crisis strategies are (expectedly) effective among SMEs during COVID-19, doi.org/10.1016/j.jbvi.2021.e00273, (2021).

10. Alyoubi, B.: Decision support system and knowledge-based strategic management, Procedia Computer Science, 65, 278-284, (2015)

11. Belardo, S., Duchessi P., Coleman, J.: A strategic decision support system at OrellFussli, Journal of Management Information Systems, 10(4), 135-157, (1994).

12. Weihrich, H.: The TOWS Matrix-A Tool for Situational Analysis. In Long Range Planning- Vol. 15, N. 2, (1982).

13. Earl, J.J.: Information systems strategy formulation In R J. Boland and R A. Hirschheim (eds.), Critical Issues in Information Systems Research. New York: John Wiley, pp. 157, (1987).

14. Ward, J., Griffiths, P.; Whitmore, P.: Strategic Planning For Information Systems. New York: John Wiley. (1990).

15. Kitsios, F., Kamariotou, M.: Decision support systems and strategic planning: information technology and SMEs' performance. International Journal of Decision Support Systems, 3(1-2), 53-70, (2018).

16. Hajimirzajana, A., Vahdat, M., Sadegheih A., Shadkam, E., El Bilali, H.: An integrated strategic framework for large-scale crop planning: sustainable climate-smart crop planning and agri-food supply chain management, volume 26, Pages 709-732, (2021)

17. Accorsi, R., Manzini R., Maranesi, F.: A decision-support system for the design and management of warehousingsystems, Computers in Industry, Vol. 65 No 1, pp. 175-186, (2014).

18. Korpela, J., Tuominen, M.: A decision aid in warehouse site selection, " International Journal of ProductionEconomics, Elsevier, vol. 45(1-3), pages 169-180, August, (1996).

19. Moormann, J., Lochte-Holtgreven, M.: An approach for an integrated DSS for strategic planning. Decision SupportSystems, 10(4), 401-411, (1993).

20. Yoo, S., Digman, L.A.: Decision support system: a new tool for strategic management', Long Range Planning, Vol.20, No. 2, pp.114-124.

21. Dung, L., Giang, P.: "Strategic responses of the hotel sector to COVID-19: Toward a refined pandemic crisismanagement framework", Volume 94, 102808, (2021)

22. Jiirgen, M., Lochte-Holtgreven, M., An approach for an integrated DS ~k.J for strategic planning , (1993).

23. Saaty, T. L.: The analytic hierarchy process in conflict management". International Journal of Conflict Management,ISSN: 1044-4068, (1990)

24. KyuLee, J., Lee H., Interaction of Strategic Planning and Short-term Planning: An Intelligent DSS by the Post-ModelAnalysis Approach, (1987)

25. Belardo, S., Duchessi, P., Coleman, R : A strategic decision support system at Orell Fussli. Journal of ManagementInformation Systems, 10(4), 135-157, (1994).

26. Hornby, R., Golder, P., Williams .A: "SDP: a strategic DSS. Decision Support Systems, 11(1), 45-51, (1994).

27. Yoo, S., Digman, L., Decision support system: A new tool for strategic management". Long Range Planning, 20(2),114-124, (1987).

28. Shahrooz, S., Hassanizadeh, B., Mohammadi, A., Kiani, B., Lau, K., Abbasi, B.: A decision support system forprioritised COVID-19 two-dosage vaccination allocation and distribution , (2022)

29. P. Beraldi, A. Violi, F. De Simone A decision support system for strategic asset allocation, (2011)

30. Cooper, R., Kaplan, R.: The Design of Cost Management Systems: Text and Cases.

31. Korpela, J., Tuominen, M.: A decision support system for strategic issues management of logistics. Internationaljournal of production economics, 46, 605-620.

32. Sprague, R., Carlson, E.: Building effective decision support systems. Prentice Hall Professional Technical Reference.(1982).

33. Zviran, M.: ISSPSS: a decision support system for information systems strategic planning. Information & management,19(5), 345-359, (1990)

34. Fanti, M., Iacobellis, G., Ukovich, W., Boschian, V., Georgoulas, G., Stylios, C.: A simulation based DecisionSupport System for logistics management. Journal of Computational Science, Vol. 10, pp. 86-96, (2015)

35. Finlay, P., Marples, C.: Strategic group decision support systems a guide for the unwary. Long Range Planning,25(3), 98-107, (1992).

36. Eden, C.: Perish the thought!. Journal of the Operational Research Society, 36(9), 809-819. (1985)
transport appraisals, Volume 72, Pages 1-15, (2015)

8. Jaziri, R., Miralama, S.: The impact of crisis and disasters risk management in COVID-19 times: Insights and lessons learned from Saudi Arabia, Medicine and Public Health 18, 100705, (2021).

9. Klyver, K., Nielsen, S.: Which crisis strategies are (expectedly) effective among SMEs during COVID-19, doi.org/10.1016/j.jbvi.2021.e00273, (2021).

10. Alyoubi, B.: Decision support system and knowledge-based strategic management, Procedia Computer Science, 65, 278-284, (2015)

11. Belardo, S., Duchessi P., Coleman, J.: A strategic decision support system at OrellFussli, Journal of Management Information Systems, 10(4), 135-157, (1994).

12. Weihrich, H.: The TOWS Matrix-A Tool for Situational Analysis. In Long Range Planning- Vol. 15, N. 2, (1982).

13. Earl, J.J.: Information systems strategy formulation In R J. Boland and R A. Hirschheim (eds.), Critical Issues in Information Systems Research. New York: John Wiley, pp. 157, (1987).

14. Ward, J., Griffiths, P.; Whitmore, P.: Strategic Planning For Information Systems. New York: John Wiley. (1990).

15. Kitsios, F., Kamariotou, M.: Decision support systems and strategic planning: information technology and SMEs' performance. International Journal of Decision Support Systems, 3(1-2), 53-70, (2018).

16. Hajimirzajana, A., Vahdat, M., Sadegheih A., Shadkam, E., El Bilali, H.: An integrated strategic framework for large-scale crop planning: sustainable climate-smart crop planning and agri-food supply chain management, volume 26, Pages 709-732, (2021)

17. Accorsi, R., Manzini R., Maranesi, F.: A decision-support system for the design and management of warehousingsystems, Computers in Industry, Vol. 65 No 1, pp. 175-186, (2014).

18. Korpela, J., Tuominen, M.: A decision aid in warehouse site selection, "International Journal of ProductionEconomics, Elsevier, vol. 45(1-3), pages 169-180, August, (1996).

19. Moormann, J., Lochte-Holtgreven, M.: An approach for an integrated DSS for strategic planning. Decision SupportSystems, 10(4), 401-411, (1993).

20. Yoo, S., Digman, L.A.: Decision support system: a new tool for strategic management', Long Range Planning, Vol.20, No. 2, pp.114-124.

21. Dung, L., Giang, P.: "Strategic responses of the hotel sector to COVID-19: Toward a refined pandemic crisismanagement framework", Volume 94, 102808, (2021)

22. Jiirgen, M., Lochte-Holtgreven, M., An approach for an integrated DS -k.J for strategic planning , (1993).

23. Saaty, T. L.: The analytic hierarchy process in conflict management". International Journal of Conflict Management,ISSN: 1044-4068, (1990)

24. KyuLee, J., Lee H., Interaction of Strategic Planning and Short-term Planning: An Intelligent DSS by the Post-ModelAnalysis Approach, (1987)

25. Belardo, S., Duchessi, P., Coleman, R : A strategic decision support system at Orell Fussli. Journal of ManagementInformation Systems, 10(4), 135-157, (1994).

26. Hornby, R., Golder, P., Williams .A: "SDP: a strategic DSS. Decision Support Systems, 11(1), 45-51, (1994).

27. Yoo, S., Digman, L., Decision support system: A new tool for strategic management". Long Range Planning, 20(2),114-124, (1987).

28. Shahrooz, S., Hassanizadeh, B., Mohammadi, A., Kiani, B., Lau, K., Abbasi, B.: A decision support system forprioritised COVID-19 two-dosage vaccination allocation and distribution , (2022)

29. P. Beraldi, A. Violi, F. De Simone A decision support system for strategic asset allocation, (2011)

30. Cooper, R., Kaplan, R.: The Design of Cost Management Systems: Text and Cases.

31. Korpela, J., Tuominen, M.: A decision support system for strategic issues management of logistics. Internationaljournal of production economics, 46, 605-620.

32. Sprague, R., Carlson, E.: Building effective decision support systems. Prentice Hall Professional Technical Reference.(1982).

33. Zviran, M.: ISSPSS: a decision support system for information systems strategic planning. Information & management,19(5), 345-359, (1990)

34. Fanti, M., Iacobellis, G., Ukovich, W., Boschian, V., Georgoulas, G., Stylios, C.: A simulation based DecisionSupport System for logistics management. Journal of Computational Science, Vol. 10, pp. 86-96, (2015)

35. Finlay, P., Marples, C.: Strategic group decision support systems a guide for the unwary. Long Range Planning,25(3), 98-107, (1992).

36. Eden, C.: Perish the thought!. Journal of the Operational Research Society, 36(9), 809-819. (1985)
37. Lee, M., Chen, I., Chen, R., Chung, C.: A target-costing based strategic decision support system. Journal of Computer Information Systems, 43(1), 110-116, (2002).

38. Thierauf, R.: User-oriented decision support systems: Accent on problem finding, International Journal of Business Intelligence Research. 9:1. (38-52), (1988).

39. Pietrzak, M., Jałosiński, K., Paliszkiewicz, J., Brzozowski, A.: A case study of strategic group map application used as a tool for knowledge management, Journal of Computer Information Systems, 55(2), 68-77, (2015).
37. Lee, M., Chen, I., Chen, R., Chung, C.: A target-costing based strategic decision support system. Journal of Computer Information Systems, 43(1), 110-116, (2002).

38. Thierauf, R.: User-oriented decision support systems: Accent on problem finding, International Journal of Business Intelligence Research. 9:1. (38-52), (1988).

39. Pietrzak, M., Jałosiński, K., Paliszkiewicz, J., Brzozowski, A.: A case study of strategic group map application used as a tool for knowledge management, Journal of Computer Information Systems, 55(2), 68-77, (2015).
Rayuela: a pluggable adaptive gamification approach
for CLCS

Dalponte Ayastuy María¹,², Alejandro Fernández¹,
and Diego Torres¹,²

¹ Depto CyT, Universidad Nacional de Quilmes

Roque Saenz Peña 352, Bernal, Buenos Aires, Argentina. /mdalponte/@unq.edu.ar

LIFIA, CICPBA-Facultad de Informatica, Universidad Nacional de La Plata 50 y 120, La Plata,
Buenos Aires, Argentina.

alejandro.fernandez,diego.torres@lifia.info.unlp.edu.ar

**Abstract.** Collaborative location-based collecting systems (CLCS) is a particular case of collaborative systems where a community of users col- laboratively collects data associated with a geo-referenced location and timestamp. This paper proposes *Rayuela* as a framework to lever existing CLCS with adaptive game challenges through a cross-project approach. This tool allows incorporating a gamification engine in a transparent way to a set of CLCS-supported citizen science projects. The game challenges are generated and adapted considering the user's profile, the project's coverage goals, area priority configuration, and global system status. Additionally, the article describes a set of extension points to combine different challenge generation and challenge recommendation strategies.

**Keywords:** *Adaptive Gamification* · *Collaborative Location-based Collection Systems* · *Game Challenges* · *Citizen Science*

# 1 Introduction

Collaborative location-based collecting systems (CLCS) is a particular case of collaborative systems where a community of users collaboratively col- lects data associated with a geo-referenced location and timestamp. Partic- ularly, the citizen science collecting systems that convene users to collect location-based data with a scientific goal, can be seen as CLCS. The con- tributions of the volunteers are known as *check-in tuples* with the structure < *position*, *timestamp*, *sample data* > [5].

Examples of CLCS-supported citizen science projects are AppEar project [3], GeoVin [4], or iNaturalist [12]. The collection task could require a mobile de- vice to fulfill a survey form or capture multimedia (images, video, sound) being located in a specific area or point. In addition, this may need to be done at a particular time or time interval.

Citizen science projects depend on the sustained participation of many peo- ple, and gamification can facilitate the engagement and retention of users [10].
Rayuela: a pluggable adaptive gamification approach
for CLCS

Dalponte Ayastuy María¹,², Alejandro Fernández¹,
and Diego Torres¹,²

¹ Depto CyT, Universidad Nacional de Quilmes

Roque Saenz Peña 352, Bernal, Buenos Aires, Argentina. /mdalponte/@unq.edu.ar

LIFIA, CICPBA-Facultad de Informatica, Universidad Nacional de La Plata 50 y 120, La Plata,
Buenos Aires, Argentina.

alejandro.fernandez,diego.torres@lifia.info.unlp.edu.ar

**Abstract.** Collaborative location-based collecting systems (CLCS) is a particular case of collaborative systems where a community of users col- laboratively collects data associated with a geo-referenced location and timestamp. This paper proposes *Rayuela* as a framework to lever existing CLCS with adaptive game challenges through a cross-project approach. This tool allows incorporating a gamification engine in a transparent way to a set of CLCS-supported citizen science projects. The game challenges are generated and adapted considering the user's profile, the project's coverage goals, area priority configuration, and global system status. Additionally, the article describes a set of extension points to combine different challenge generation and challenge recommendation strategies.

**Keywords:** *Adaptive Gamification* · *Collaborative Location-based Collection Systems* · *Game Challenges* · *Citizen Science*

# 1 Introduction

Collaborative location-based collecting systems (CLCS) is a particular case of collaborative systems where a community of users collaboratively col- lects data associated with a geo-referenced location and timestamp. Partic- ularly, the citizen science collecting systems that convene users to collect location-based data with a scientific goal, can be seen as CLCS. The con- tributions of the volunteers are known as *check-in tuples* with the structure < *position*, *timestamp*, *sample data* > [5].

Examples of CLCS-supported citizen science projects are AppEar project [3], GeoVin [4], or iNaturalist [12]. The collection task could require a mobile de- vice to fulfill a survey form or capture multimedia (images, video, sound) being located in a specific area or point. In addition, this may need to be done at a particular time or time interval.

Citizen science projects depend on the sustained participation of many peo- ple, and gamification can facilitate the engagement and retention of users [10].
Gamification is the application of game elements and mechanics (like points, badges, leaderboards, storytelling, etc) in contexts where people's task is not simply to play [6]. Nevertheless, this paper will focus on game challenges, which are tasks or problems whose difficulty depends on the user's skills, abilities, motivation, and knowledge [11]; considering each collection task (or a set of them) as a game challenge and the areas of CLCS's territory as a game board. In addition, the combination of the spatial and temporal constraints of the collection tasks builds up an idea of difficulty and reward that are considered game mechanics. Despite the advances in gamification research and its demonstrated benefits related to user engagement and activity, these benefits are considered context-specific and not generalizable to all individuals [8]. The *one-size-fits-all* approach presents several limitations because of the users' different motivations, personalities, needs, and playing styles [2, 9, 1]. Currently, the research stream on adaptive gamification is considering how to dynamically adapt the game elements and mechanics each user needs in each context. The gamification approach could be adapted to the community members and the project's goals for better participation and sustained user engagement.

Assessing the impact of a given adaptive gamification strategy empirically presents several challenges. On the one hand, it is necessary to demonstrate that a scenario with adaptive gamification is better than one where gamification is not adaptive (and it is possibly also better than one without gamification). Therefore, the evaluation should develop two parallel case studies on a real-world CLCS. On the other hand, considering that CLCS can have support tools (digital or not), it is necessary to propose a mechanism that allows the application of an adaptive gamification approach transparently. Also, researchers need to agilely and with low effort change the key aspects of adaptive gamification to generate the various case studies (by tuning the challenge generation and the recommendation strategies).

With this objective in mind, this article proposes *Rayuela*, an approach to adaptively gamify existing CLCS citizen science projects as an external application. Moreover, it can be set up with more than one existing CLCS project, thus consolidating a platform of gamified projects. In addition, it offers extension points so researchers can plug in new game challenges generation and recommendation strategies. It allows managers of citizen science projects to monitor the progress of game players and assess the impact of gamification in their projects. The following sections are organized as follows. In Section 2 the approach is presented and the uses cases are explained. Finally, Section 3 shares conclusions and future work.

## 2 Approach

An overview of the challenge-based adaptive gamification approach is provided by Figure 1. An existing citizen science project (gray box in the Figure) defines tasks for volunteers to complete, and is not yet gamified. The tasks are collection tasks characterized by time and space restrictions. Volunteers complete the tasks using the tools provided by the citizen science project managers (gray row), which can be a mobile application, a web application, or some non-digital technology.
Gamification is the application of game elements and mechanics (like points, badges, leaderboards, storytelling, etc) in contexts where people's task is not simply to play [6]. Nevertheless, this paper will focus on game challenges, which are tasks or problems whose difficulty depends on the user's skills, abilities, motivation, and knowledge [11]; considering each collection task (or a set of them) as a game challenge and the areas of CLCS's territory as a game board. In addition, the combination of the spatial and temporal constraints of the collection tasks builds up an idea of difficulty and reward that are considered game mechanics. Despite the advances in gamification research and its demonstrated benefits related to user engagement and activity, these benefits are considered context-specific and not generalizable to all individuals [8]. The *one-size-fits-all* approach presents several limitations because of the users' different motivations, personalities, needs, and playing styles [2, 9, 1]. Currently, the research stream on adaptive gamification is considering how to dynamically adapt the game elements and mechanics each user needs in each context. The gamification approach could be adapted to the community members and the project's goals for better participation and sustained user engagement.

Assessing the impact of a given adaptive gamification strategy empirically presents several challenges. On the one hand, it is necessary to demonstrate that a scenario with adaptive gamification is better than one where gamification is not adaptive (and it is possibly also better than one without gamification). Therefore, the evaluation should develop two parallel case studies on a real-world CLCS. On the other hand, considering that CLCS can have support tools (digital or not), it is necessary to propose a mechanism that allows the application of an adaptive gamification approach transparently. Also, researchers need to agilely and with low effort change the key aspects of adaptive gamification to generate the various case studies (by tuning the challenge generation and the recommendation strategies).

With this objective in mind, this article proposes *Rayuela*, an approach to adaptively gamify existing CLCS citizen science projects as an external application. Moreover, it can be set up with more than one existing CLCS project, thus consolidating a platform of gamified projects. In addition, it offers extension points so researchers can plug in new game challenges generation and recommendation strategies. It allows managers of citizen science projects to monitor the progress of game players and assess the impact of gamification in their projects. The following sections are organized as follows. In Section 2 the approach is presented and the uses cases are explained. Finally, Section 3 shares conclusions and future work.

## 2 Approach

An overview of the challenge-based adaptive gamification approach is provided by Figure 1. An existing citizen science project (gray box in the Figure) defines tasks for volunteers to complete, and is not yet gamified. The tasks are collection tasks characterized by time and space restrictions. Volunteers complete the tasks using the tools provided by the citizen science project managers (gray ar-row), which can be a mobile application, a web application, or some non-digital technology.
<figure><img src="image_39.png" /><figcaption>**Fig. 1.** Approach architecture</figcaption></figure>

*Rayuela* platform adds an adaptive gamification layer to the citizen science project. Using it, the volunteer enriches her participation in the project, particularly by selecting in *Rayuela* the tasks to be completed and login them when finished. Playful activities are proposed to accomplish the project tasks based on criteria established by the project manager -who configures the spatial and temporal restrictions and task types-. In proposing activities, *Rayuela* also considers the profile of the volunteer (the history of solved and unsolved tasks and traveling behavior).

*Rayuela* architecture has two main modules, the project setup, and the game engine. The first one stores the configuration provided by the project manager. The second one has the function of providing game challenges to the volunteer. Likewise, the game engine has 3 extensible components. Firstly, the user profile gathers all the explicit and implicit information about the user's preferences, characteristics, and behavior. Secondly, the game challenge generator builds a set of game challenges by applying strategies based on the project manager configurations. Lastly, the game challenge recommender builds an ordered list of game challenges from the user's profile and the project's goals.

These components can be seen as framework extensions. For instance, the generation of the challenges can be done manually by the manager of the gamified project or automatically, applying an exhaustive strategy or taking into account both the user's historical behavior and the status of coverage of the project's goals. Also, the recommendation of challenges can be approached with different strategies, more or less computationally demanding to consider more or fewer aspects of the information retrieved about the user. For example, a recommendation system can consider multiple criteria, prioritizing tasks according to project goals, or also the spatiotemporal behavior of the user.

The framework use cases are presented through the interaction among the users and the framework, considering two user roles: on the one hand, the project manager role and, on the other hand, the volunteer role.
<figure><img src="image_53.png" /><figcaption>Fig. 1. Approach architecture</figcaption></figure>

*Rayuela* platform adds an adaptive gamification layer to the citizen science project. Using it, the volunteer enriches her participation in the project, particularly by selecting in *Rayuela* the tasks to be completed and login them when finished. Playful activities are proposed to accomplish the project tasks based on criteria established by the project manager -who configures the spatial and temporal restrictions and task types-. In proposing activities, *Rayuela* also considers the profile of the volunteer (the history of solved and unsolved tasks and traveling behavior).

*Rayuela* architecture has two main modules, the project setup, and the game engine. The first one stores the configuration provided by the project manager. The second one has the function of providing game challenges to the volunteer. Likewise, the game engine has 3 extensible components. Firstly, the user profile gathers all the explicit and implicit information about the user's preferences, characteristics, and behavior. Secondly, the game challenge generator builds a set of game challenges by applying strategies based on the project manager configurations. Lastly, the game challenge recommender builds an ordered list of game challenges from the user's profile and the project's goals.

These components can be seen as framework extensions. For instance, the generation of the challenges can be done manually by the manager of the gamified project or automatically, applying an exhaustive strategy or taking into account both the user's historical behavior and the status of coverage of the project's goals. Also, the recommendation of challenges can be approached with different strategies, more or less computationally demanding to consider more or fewer aspects of the information retrieved about the user. For example, a recommendation system can consider multiple criteria, prioritizing tasks according to project goals, or also the spatiotemporal behavior of the user.

The framework use cases are presented through the interaction among the users and the framework, considering two user roles: on the one hand, the project manager role and, on the other hand, the volunteer role.
## 2.1 Project manager role interactions

As was previously mentioned in Section 2, this role is in charge of configur-ing the project setup that relates to the needs and objectives of the project. Each gamified project's manager must be able to describe the project, definetask types (e.g. survey, photo or video capture, etc.), define work areas, define time constraints for tasks, and configure game challenges. Moreover, the definition of these aspects is a precondition for the generation/configuration of game challenges (as seen in the bottom timeline of Figure 2).

**Project setup** The setup of the adaptive gamified project needs the definition of the work areas, the time restriction and the task types.

**Game Challenges Generation** The generation of game challenges can be approached with different levels of suitability. The most straightforward approach is manual loading, with a choice of area, time restriction, type and the number of tasks. Another option is the exhaustive generation of game challenges resulting from combining all areas, time restrictions, and task types. Moreover, other approaches related to the project's coverage goals can be considered. A more complex approach can use as input, the coverage setting in terms of sample amount -by task type-, and the area priority.

<figure><img src="image_40.png" /><figcaption>Fig. 2. *Rayuela* swimlanes</figcaption></figure>

## 2.2 Volunteer role interactions

By interacting with *Rayuela* the volunteer can browse a set of game challenges that were generated from the project setup and recommended based on her profile. By choosing one game challenge from the list, she commits to performing the tasks requested by the challenge, which are carried out externally using the citizen science project. Each completed task must be logged in *Rayuela* to show progress in the game. In addition, the volunteer can express her opinion about the challenge she completed by providing a score.

The volunteer's gamified experience is composed of the interactions described in volunteer's swimlane of Figure 2.
## 2.1 Project manager role interactions

As was previously mentioned in Section 2, this role is in charge of configur-ing the project setup that relates to the needs and objectives of the project. Each gamified project's manager must be able to describe the project, definetask types (e.g. survey, photo or video capture, etc.), define work areas, define time constraints for tasks, and configure game challenges. Moreover, the definition of these aspects is a precondition for the generation/configuration of game challenges (as seen in the bottom timeline of Figure 2).

**Project setup** The setup of the adaptive gamified project needs the definition of the work areas, the time restriction and the task types.

**Game Challenges Generation** The generation of game challenges can be approached with different levels of suitability. The most straightforward approach is manual loading, with a choice of area, time restriction, type and the number of tasks. Another option is the exhaustive generation of game challenges resulting from combining all areas, time restrictions, and task types. Moreover, other approaches related to the project's coverage goals can be considered. A more complex approach can use as input, the coverage setting in terms of sample amount -by task type-, and the area priority.

<figure><img src="image_54.png" /><figcaption>Fig. 2. *Rayuela* swimlanes</figcaption></figure>

## 2.2 Volunteer role interactions

By interacting with *Rayuela* the volunteer can browse a set of game challenges that were generated from the project setup and recommended based on her profile. By choosing one game challenge from the list, she commits to performing the tasks requested by the challenge, which are carried out externally using the citizen science project. Each completed task must be logged in *Rayuela* to show progress in the game. In addition, the volunteer can express her opinion about the challenge she completed by providing a score.

The volunteer's gamified experience is composed of the interactions described in volunteer's swimlane of Figure 2.
**User's registration and personalization** The user registers to the application *Rayuela* and personalizes her profile. The profile personalization -the change of information, adjustments, or other parameters to a player's personal preferences, abilities, needs, or requirements [7]- is an important stage as it allows the user to take ownership of the platform. Her profile can include data about her life if she has a car, or how old she is. Personal information can be an input for the recommendation process.

**Subscription to a project** The user can browse the active citizen science projects in the platform and join one of them to enable the game challenges assignment (see Screen (A) in Figure 3). This can be seen as she wants to play that project's game.

**Game challenge recommendation** The user is offered a set of game elements based on her game profile and spatiotemporal behavior in relation to the CLCS. CLCS needs to optimize volunteers' work by combining the defined objectives for the CLCS with the completed tasks in the territory and the implicitly expressed preferences. This recommendation stage can be seen as a multi-criteria recommendation since the game challenges list is built considering, on the one hand, what is needed to achieve the project objectives and, on the other hand, the user's behavior profile, preferences, and characteristics. See an example game challenge recommendation in Figure 3 B. Each game challenge sets a goal for the user, expressed by an area, a time restriction, and a type and number of tasks. Also, the game challenge presents a difficulty level and a reward to the user.

**Game challenge assignment**

The user chooses a game challenge from the recommended list, that represents a commitment to perform a certain task in a specific area and a specific time interval. By choosing an element from the ordered list, the user expresses her preferences. The underlying idea is to derive the user's preferences by having her choose a game element from a list sorted by the estimated user score. Assuming the example in Figure 3 (B), the user may select the third game challenge (with Area: *Reserva El destino*, time restriction: week days, task type: survey and 1 sample), which has the lowest score in the recommended list. This will trigger a profile update that will improve the recommendations.

**Check-in registration** The user moves to a sampling area and completes the sampling task, generating a check-in tuple through the **citizen science application**. The user does a collection task (that can be of different types -e.g. completing a scientific survey, capturing photos or videos, among others- using an external application (see the upper swimlane in Figure 2) for a specific citizen science project. The user registers the newly generated check-in through the *Rayuela* application. This action must take the data from the mobile device through the GPS and clock to ensure the user is located in the informed geographic coordinate and timestamp (as seen in Figure 3-C).

**Game status feedback** The user receives feedback from the gamification layer regarding the state of the game. The recently completed check-in can contribute to the progress in more than one game challenge within the project, and therefore the registration of the check-in should compute the progress in all possible active game challenges. Users must be aware of their game progress by means of some kind of gamification resource, e.g. a progress bar (see Figure 3-D).

**Game challenge scoring** The user can give explicit feedback about a completed game element through a multi-criteria scoring device. When the user completes a challenge (see bottom challenge in Figure 3-D), the possibility of rating the game challenge is enabled in three ways: through a choice between like and dislike, through an overall score for the game challenge (single criteria rating) or through a detailed score in several criteria: the area, the time restriction, the number of samples, the difficulty or the obtained reward (multi-criteria rating). These expressed preferences must be used to update the user profile and contribute to better recommendations.
**User's registration and personalization** The user registers to the application *Rayuela* and personalizes her profile. The profile personalization -the change of information, adjustments, or other parameters to a player's personal preferences, abilities, needs, or requirements [7]- is an important stage as it allows the user to take ownership of the platform. Her profile can include data about her life if she has a car, or how old she is. Personal information can be an input for the recommendation process.

**Subscription to a project** The user can browse the active citizen science projects in the platform and join one of them to enable the game challenges assignment (see Screen (A) in Figure 3). This can be seen as she wants to play that project's game.

**Game challenge recommendation** The user is offered a set of game elements based on her game profile and spatiotemporal behavior in relation to the CLCS. CLCS needs to optimize volunteers' work by combining the defined objectives for the CLCS with the completed tasks in the territory and the implicitly expressed preferences. This recommendation stage can be seen as a multi-criteria recommendation since the game challenges list is built considering, on the one hand, what is needed to achieve the project objectives and, on the other hand, the user's behavior profile, preferences, and characteristics. See an example game challenge recommendation in Figure 3 B. Each game challenge sets a goal for the user, expressed by an area, a time restriction, and a type and number of tasks. Also, the game challenge presents a difficulty level and a reward to the user.

## Game challenge assignment

The user chooses a game challenge from the recommended list, that represents a commitment to perform a certain task in a specific area and a specific time interval. By choosing an element from the ordered list, the user expresses her preferences. The underlying idea is to derive the user's preferences by having her choose a game element from a list sorted by the estimated user score. Assuming the example in Figure 3 (B), the user may select the third game challenge (with Area: *Reserva El destino*, time restriction: week days, task type: survey and 1 sample), which has the lowest score in the recommended list. This will trigger a profile update that will improve the recommendations.

**Check-in registration** The user moves to a sampling area and completes the sampling task, generating a check-in tuple through the **citizen science application**. The user does a collection task (that can be of different types -e.g. completing a scientific survey, capturing photos or videos, among others- using an external application (see the upper swimlane in Figure 2) for a specific citizen science project. The user registers the newly generated check-in through the *Rayuela* application. This action must take the data from the mobile device through the GPS and clock to ensure the user is located in the informed geographic coordinate and timestamp (as seen in Figure 3-C).

**Game status feedback** The user receives feedback from the gamification layer regarding the state of the game. The recently completed check-in can contribute to the progress in more than one game challenge within the project, and therefore the registration of the check-in should compute the progress in all possible active game challenges. Users must be aware of their game progress by means of some kind of gamification resource, e.g. a progress bar (see Figure 3-D).

**Game challenge scoring** The user can give explicit feedback about a completed game element through a multi-criteria scoring device. When the user completes a challenge (see bottom challenge in Figure 3-D), the possibility of rating the game challenge is enabled in three ways: through a choice between like and dislike, through an overall score for the game challenge (single criteria rating) or through a detailed score in several criteria: the area, the time restriction, the number of samples, the difficulty or the obtained reward (multi-criteria rating). These expressed preferences must be used to update the user profile and contribute to better recommendations.
## 3 Conclusion and Future work

Rayuela is a gamification platform that can be set up with several citizen science projects and is transparent to the collaboration tools they already have. It allows participating in more than one citizen science project, choosing among a project-specific list of generated and recommended game elements for the player, recording the completion of sampling tasks, and being aware of the progress in the game.

Citizen science projects may apply adaptive gamification to have greater participation from the general public and reach a higher project efficiency.

This tool allows incorporating a gamification engine in a transparent way to a set of CLCS-supported citizen science projects. It also allows materializing a platform of gamified projects that has several advantages. On the one hand, people's linkage for a project can be transferred to other projects, since people discover new projects through the platform. On the other hand, by joining a new project, the user does not start from scratch. This project capitalizes on the experience and knowledge the person acquired by participating in other projects.

<figure><img src="image_41.png" /><figcaption>Fig. 3. Rayuela screens: gamified projects list (A), recommended challenges for user (B), check-in registration (C), and game layer feedback (D)</figcaption></figure>

The challenge-based gamification approach considered the user's profile, the project's coverage goals, area priority configuration, and global system status to adapt the game challenges.

As further work, the inclusion of other game elements and mechanics will be analyzed.

## Acknowledgements

This article publication is based upon the work of the Project RUN Citizen science and co-creation for regeneration of urban rivers and mitigation of risks, which has received funding from the CYTED Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo, under grant agreement No 420RT0008, http://cyted.org/es/run.