ʻ ‘

# Rename Chains: An Exploratory Study on the Occurrence and Characteristics of
Identifiers Undergoing Multiple Renamings

Anthony Peruma  Information and Computer Sciences Department
University of Hawaiʻi at Mānoa
Honolulu, Hawaiʻi, USA
<EMAIL_ADDRESS>Christian D. Newman  Department of Software Engineering
Rochester Institute of Technology
Rochester, New York, USA
<EMAIL_ADDRESS>
###### Abstract

Identifier names play a significant role in program comprehension activities,
with high-quality names improving developer productivity and system quality.
To correct poor-quality names, developers rename identifiers to reflect their
intended purpose better. However, renames do not always result in high-
quality, long-lasting names; in many cases, developers perform multiple rename
operations on the same identifier throughout the system’s lifetime. In this
paper, we report on a large-scale empirical study that examines the occurrence
of identifiers undergoing multiple renames (i.e., rename chains). Our findings
show the presence of rename chains in almost every project, with methods
typically having more rename chains than other identifier types. Furthermore,
it is usually the same developer responsible for creating all renames within a
chain, with most names maintaining the same grammatical structure.
Understanding rename chains can help us provide stronger advice, and targeted
research, on how to craft high-quality, long-lasting identifiers.

##  I Introduction

Be it bug fixing or updating features, program comprehension is an essential
part of any software maintenance activity [1]. Program comprehension is the
act of developers reading the code to understand its behavior in order to know
where to make updates to the source code [2]. Therefore, to ensure both
developer productivity and system quality, it is essential for developers to
craft identifiers with meaningful names. In other words, the name should
accurately reflect its intended behavior.

Research shows that identifier names account for almost 70% of the characters
in a software system’s codebase [3], with well-constructed names improving
comprehension activities by an estimated 19% [4]. Unfortunately, there are
significant problems with many identifiers, and no generalizable methods to
measure identifier quality. This is likely part of the reason renaming is one
of the most frequent types of rework (i.e., refactoring) developers perform on
their code base, contributing to around 40% of the rework developers perform
throughout the lifetime of the system [5, 6, 7].

While Rename Refactoring is the approach developers take to correct poor-
quality names, there is no guarantee that the resulting new name is of high
quality, with developers sometimes performing multiple rename operations to
the same identifier. For instance, let us compare the code snippets in Listing
1 and Listing 2, both of which show multiple renamings of a method’s name. In
Listing 1, the developer renames the method
sendPacket2$\rightarrow$sendPacket3$\rightarrow$syncedSendPacket. The original
and first iteration of the name contain digits, and this type of naming is
known as a Distinguisher [8]. Developers utilize such names to prevent name
collisions at compile time when multiple identifiers with the same name are in
the class/file. The final version of the name, syncedSendPacket, is no longer
a Distinguisher and is more descriptive than the original. In contrast, it can
be argued that the end result of the method rename in Listing 2 does not
produce a high-quality name as println is a copy of the statement inside the
method and provides no additional information.

Even though prior work on identifier naming examines the lexical semantic
updates developers make to a name when performing the rename operation [9, 6,
5, 10], they fall short of investigating how each identifier evolves
throughout the system’s entire lifetime. In other words, they do not examine
if the individual rename operations are related to each other. Likewise,
studies that propose rename opportunities in the code do not consider the
historical evolution of the identifiers [11, 12, 13].

⬇

\- public void sendPacket2(Packet9Respawn packet) {

\+ public void sendPacket3(Packet9Respawn packet) {

\- public void sendPacket3(Packet9Respawn packet) {

\+ public void syncedSendPacket(Packet9Respawn packet) {

activeChunks.clear();

super.sendPacket(packet);

}

Listing 1: An example of a method name undergoing multiple renames to make it
more descriptive of its purpose ([14]$\rightarrow$[15]).

⬇

\- public void writeMessage(String message) {

\+ public void info(String message) {

\- public void info(String message) {

\+ public void println(String message) {

systemOut.println(message);

}

Listing 2: An example of a rename chain resulting in a weak method name; it is
just a copy of the statement within the method ([16]$\rightarrow$[17]).

###  I-A Goal & Research Questions

The goal of this study is to explore the evolution of identifier names by
constructing and studying the characteristics of a chain of renames for
identifiers (i.e., a rename chain). Through the findings from our study, we
aim to understand the multiple rename refactoring operations developers
perform on an identifier that can feed into tools and techniques to better
support developers with crafting and maintaining identifiers in their code.
Therefore, we propose and answer the following research questions (RQs):

RQ1: To what extent do identifiers undergo multiple rename refactoring
operations? This RQ reports on the volume and types of identifiers that
undergo multiple renames during their lifetime and how frequently they occur
in projects. Knowing the popularity of rename chains in a project’s evolution
will direct us to further research in this area.

RQ2: How frequently do renames occur within a rename chain, and who is
responsible for their creation? From this RQ, we gain insight into the
developers performing the renames in the chain and how frequently developers
perform the rename operations within the chains. By considering the developers
responsible for creating rename chains, rename recommendation techniques can
improve their accuracy and usability.

RQ3: How do the semantics of an identifier’s name evolve in a rename chain?
This RQ analyzes the lexical-semantic properties of the renames by comparing
the part-of-speech tags of the first and last names in the chain. Findings and
heuristics from this RQ can be incorporated into automated identifier name
appraisal and recommendation tools and techniques.

RQ4: To what extent can commit log messages help contextualize the occurrence
of rename chains? Using the generated rename chains in our dataset, this RQ
examines how effectively commit messages can identify the specific causes for
developers to create rename chains.

###  I-B Contribution

The main contributions from this work are as follows:

  * •

Our results represent a significant step toward understanding how an
identifier’s name evolves through the project’s lifetime. Through our
discussion, we pave the way for subsequent research to enhance our knowledge
of high-quality identifier naming, especially in automated identifier name
appraisal and recommendation tools.

  * •

We make our dataset of rename chains, including specific characteristics of
the renames, publicly available.

##  II Related Work

This section discusses the work related to identifier renaming. Broadly, these
studies fall into two categories, empirical studies that examine the semantic
characteristics of names and studies that propose rename recommendation
techniques/models.

###  II-A Empirical Studies

In a developer survey, Arnoudova et al. [9] report that developers perform
renaming as part of their implementation workflow and admit that renaming is
not straightforward. Furthermore, the authors propose a taxonomy to classify
the types of semantic updates a name undergoes when renamed.

An empirical examination by Peruma et al. [6] of the semantic updates
developers make to a name shows that developers frequently make simple renames
by adding or removing a single term in a name. Further, the authors also show
that developers frequently narrow the meaning of the name. The authors also
highlight specific grammar patterns developers utilize when crafting unit test
method names [10] and produce a taxonomy of digits occurring in an
identifier’s name [8]. Additionally, as a means of contextualizing the renames
developer perform, Peruma et al. [5] show relationships between the data type
and the plurality of the name. Specifically, the name changes from singular to
plural when the data type changes from a non-collection to a collection type.
The authors also show that specific identifier renamings tend to co-occur with
other types of refactoring operations. Further, the authors also show that
novice developers tend to perform more renames than other types of refactoring
operations [18].

###  II-B Rename Recommendations

A model called NATURALIZE that uses statistical natural language processing to
mine and learn the style (i.e., coding norms) of a codebase and offers
renaming recommendations are introduced by Allamanis et al. in their paper
[11]. To standardize names used in related contexts, NATURALIZE learns
syntactic restrictions, or sub-grammars, on identifier names like camelcase or
underscore. The authors also recommend a neural probabilistic language model
to automatically suggest descriptive, idiomatic method and class names [12].
An n-gram based approach for assessing the comprehensibility of method names
and recommending intelligible method names is introduced by Suzuki et al.
[13]. The authors’ solution involves gathering and learning method names from
Java systems. The authors employ the n-gram model to provide recommendations
to the developer and a threshold to assess the comprehensibility score of a
method’s name as part of their analysis process. Deep learning methods are
used by Liu et al. [19] to spot incorrect method names. Their methodology
retrieves in-depth representations of method bodies and names. The model is
trained by the authors using numerous techniques from actual projects. The
name recommendation method compares the overlap between the set of method
names whose bodies are close in the method body vector space and the closeness
of method names in the method name vector space.

##  III Experiment Design

Figure 1: Overview of our experiment design.

In this section, we provide details about the methodology for our study.
Figure 1 shows a high-level overview of our experiment, which we describe in
detail below. Furthermore, the dataset we utilize/generate in this study is
available on our project website for replication and extension purposes [20].

###  III-A Source Dataset

In this study, we utilize an existing dataset of mined refactoring operations
made available by Peruma et al. [10] from their research on test method name
renaming and resued by the authors in another study on identifier names [8].
The authors of the dataset utilized RefactoringMiner [21] to mine the
refactoring operations of 800 well-engineered open-source Java systems.
RefactoringMiner is a state-of-the-art tool that iterates through a project’s
commit log mining refactoring operations. The dataset contains mined rename
refactoring operations for classes, attributes, methods, parameters, and
variables.

###  III-B Rename Chain Construction

Our manual analysis of the source dataset shows the presence of auto-generated
code related to projects utilizing Antlr. Since such code could skew our
findings, we first exclude such source files from our analysis; our dataset
contains the query we used to perform the exclusion. After performing this
exclusion, we start the work of constructing the rename chain for each
identifier type, using custom scripts. Our approach involves the use of the
fully qualified name of the identifier to perform name comparisons to form
links in the chain. The general approach involves first obtaining the
refactorings for each identifier type sorted by the author commit date for
each project. Next, for each type of identifier rename refactoring in the
project, we search for instances where the new name in the refactoring is the
old name in a subsequent rename operation. If such a match exists, it forms a
link in the chain. This process continues recursively. Our replication package
contains the code utilized to create the chains for each identifier type.

###  III-C Part-of-Speech Tagging

To understand the semantic change to an identifier’s name, we utilize a
specialized identifier name part-of-speech tagger made available by Newman et
al. [22]. This is a state-of-the-art tagger that outperforms other taggers,
including the Stanford tagger [23], for identifier names. The tagger utilizes
a subset of the Penn Treebank tagset [24] and includes nouns, verbs, noun
modifiers, determiners, etc; details of which are available at [25]. Using
this tagger, we generate the part-of-speech tags for each term in an
identifier’s name for the original and last name in the rename chain.

###  III-D Topic Modeling

To contextualize the presence of rename chains, we perform a topic modeling
analysis utilizing the latent Dirichlet allocation (LDA) algorithm [26].
Before performing the topic modeling analysis, we perform a set of text
preprocessing tasks on the commit messages; we remove non-alphabet characters,
such as punctuations, set the text to lowercase, lemmatize words, and finally,
remove standard English stopwords. To arrive at the optimal number of topics,
we iteratively extracted topics from two to ten in increments of one, where
each topic execution cycle had 100 passes and 200 iterations. We manually
examined the word frequencies present in each topic cycle to determine the
optimum topic.

###  III-E Research Question Analysis

To answer our research questions, we follow a mixed methods approach, where we
supplement our quantitative findings with qualitative examples from our
dataset. This technique helps us understand our results through
contextualization. We employ custom scripts and database queries to answer our
research questions and elaborate on our approach when addressing each research
question in Section IV.

TABLE I: Volume of mined rename operations for each identifier type. | Identifier
---
Type
| Total Rename
---
Refactoring Operations
Percentage
Method | 84,321 | 29.50%
Parameter | 72,972 | 25.53%
Variable | 62,059 | 21.75%
Attribute | 35,741 | 12.51%
Class | 30,693 | 10.74%
All | 285,786 | 100%

##  IV Experiment Results

In this section, we report on the findings of our experiments. Since our work
is based on the rename refactoring operations performed on identifiers, we
first present an overview of renames in our dataset. In total, our dataset
contains 285,786 rename refactorings spread across the five identifier types.
Table I shows the volume of renames by identifier type, most of which were
method renames (29.50%).

Moving on, we focus our analysis on rename chains by answering our RQs. The
first RQ examines the volume of rename chains present in the dataset, while
The second and third RQ investigates specific characteristics of these rename
chains. Due to space constraints, specific tables in the RQs show only the
most frequently occurring instances; the complete set is available on our
project website [20].

###  IV-A RQ1: To what extent do identifiers undergo multiple rename
refactoring operations?

In this RQ, we quantitatively analyze the rename chains in our dataset. In
total, we mined 285,786 rename refactoring operations. We then analyzed this
raw data to construct rename chains. A chain is a combination of rename
operations applied to a single identifier. We construct a chain if two or more
rename operations are applied to an identifier. In total, we detected 17,404
rename chains spread across all identifier types. In contrast, our dataset
contains 247,567 identifiers that underwent only a single rename operation
and, hence do not form a chain. A granular examination shows that, out of all
identifier types in our dataset, methods (approx. 30.73%) are most likely to
have rename chains, followed by variables (approx. 23.47%), classes (16.85%),
parameters (approx. 16.81%), and attributes (approx. 12.14%). Table II
provides an overview of the mined rename chains.

TABLE II: Volume of identifiers with a single rename and multiple rename instances for each identifier type. Identifier Type |  Instances with a single rename |  | Instances with more than one rename
---
(i.e., rename chain)
Count | Percentage
Class | 24,221 | 2,933 | 16.85%
Attribute | 31,245 | 2,113 | 12.14%
Method | 72,884 | 5,349 | 30.73%
Parameter | 66,015 | 2,925 | 16.81%
Variable | 53,202 | 4,084 | 23.47%
All | 247,567 | 17,404 | 100.00%

Moving on, we focus on the number of rename operations that form a rename
chain. Overall, an identifier rename chain contains a median of 2 and an
average of 9 rename instances. On a granular level, we observe that classes,
attributes, methods, and parameters have a median of two renames in their
chains, while variables have three rename instances. Table III shows a
statistical summary of the number of rename instances for each identifier type
in their rename chain.

TABLE III: Statistical summary of the number of rename instances associated with each type of identifier. Min. | 1st Qu. | Median | Mean | 3rd Qu. | Max.
---|---|---|---|---|---
Class
2 | 2 | 2 | 2.23 | 2 | 7
Attribute
2 | 2 | 2 | 2.16 | 2 | 6
Method
2 | 2 | 2 | 2.17 | 2 | 8
Parameter
2 | 2 | 2 | 2.49 | 2 | 53
Variable
2 | 2 | 3 | 31.09 | 55 | 143

Finally, while our dataset contains 798 projects having rename refactorings,
668 (or 83.71%) of these projects contain rename chains. Looking at the volume
of rename chains within these projects, we observe that projects have a median
of nine and a mean of 26.05 identifiers undergoing multiple renames.

Summary for RQ1. Though rename operations are prevalent in the implementation
and maintenance of software systems, most identifiers typically undergo a
single rename throughout their lifetime. However, rename chains are present in
most systems. Method names typically undergo multiple renamings and typically
contain around two renames in their rename chain. Variables, on the other
hand, undergo around three renamings.

###  IV-B RQ2: How frequently do renames occur within a rename chain, and who
is responsible for their creation?

In the prior RQ, we show the occurrence of rename chains in the evolution of
the code base of a software system. Moving on, this RQ examines the renames
occurring within these chains. More specifically, we investigate the interval
duration between the renames in the chains and the developers performing these
renames. The findings from this RQ help us better understand the
characteristics of rename chains.

Interval Analysis

This analysis examines the interval (i.e., time duration) between renames in
chains having two or more rename instances. An overall examination of the
median number of days between renames shows that the renames occur two days
apart. Next, in a more granular examination, we observe that attributes have a
median of 25 days, followed by classes having 19 days, methods with 14 days,
parameters with seven days, and variables having two days between renames in
the chain.

Our subsequent examination looks at the interval between the first and last
rename in the chain. Parameters have the lowest interval with a median of 17
days between the first and last rename. In contrast, variables have the
longest of 357 days between the first and last rename in the chain. Finally,
classes, attributes, and methods have an interval of 32, 35, and 22 days,
respectively.

Developer Analysis

In this analysis, we investigate who performs the renames involved in the
rename chain. To this extent, we utilize the email address associated with the
commit containing the rename (i.e., git author email). Prior studies have used
the email address to determine unique developers, including those that examine
identifier renaming [5]. Our analysis is on chains having two or more rename
instances.

First, the same developer performs just over half of the rename chains (i.e.,
10,799 or 62.05% instances). Next, focusing on the chains having multiple
developers, we observe that 760 or 11.51% of instances have a different
developer performing the first and last rename in the chain. Furthermore,
these multi-developer chains have a median and average of approximately two
unique developers performing the renames in the chain. At a more granular
level, attribute chains have the most developers involved in the rename
process, with a median of four developers, followed by variables with a median
of three. Class and method chains have a median of two developers performing
the renames in their respective chains.

Summary for RQ2. Rename chains are typically constructed with rename
refactoring operations that occur days apart, with variables typically having
the shortest duration (approx. two days) and attributes the longest.
Furthermore, rename chains are usually constructed by the same developer.
Finally, multi-developer chains usually involve two developers, with the
construction of attribute chains involving more developers than other
identifier rename chains.

###  IV-C RQ3: How do the semantics of an identifier’s name evolve in a rename
chain?

This RQ continues our analysis of the evolution of renames chains by examining
the lexical-semantic structure of the identifier names in the chain. Our
analysis includes examining the part-of-speech tags instead of the semantics
of actual word since the tags are more constrained and leave less room for
misinterpretation. Furthermore, prior work has shown that developers utilize
specific grammatical patterns when crafting identifier names [27]. To this
extent, we utilize a specialized ensemble tagger for identifier names ([22])
to generate the part-of-speech tags for the words in an identifiers name.

Since a chain can be composed of a varying number of renames, comparing and
analyzing each and every rename within the chain is not feasible. Hence, we
limit our analysis to the first and last rename in the chain. In other words,
we compare the name of the identifier before the first rename and the name of
the identifier after the final rename. Our analysis shows that 7,266 or 41.75%
rename chains have the same part-of-speech pattern for the original and final
name.

Next, we examine the common part-of-speech patterns utilized for the original
and final names for each identifier type. Shown in Table IV are the top three
widely used part-of-speech tags for the original and final name for each
identifier type. From this table, we observe that the majority of the commonly
used part-of-speech tags for both names are the same. For example, in the
class rename chain
TestServlet$\rightarrow$TheTestServlet$\rightarrow$TestServlet
([28]$\rightarrow$[29]), the part-of-speech pattern starts with NM—N, then
changes to DT—NM—N when the developer prepends the determiner “The” to the
name, before finally reverting the name structure to NM—N. The complete set of
part-of-speech patterns are available in our shared dataset.

Furthermore, it is encouraging to note that developers utilize standard naming
structures when crafting names for identifiers [27]. From Table IV, we can see
that classes, attributes, parameters, and variables begin with either a
noun/noun-plural (N/NPL) or noun modifier (NM), while methods start with a
verb (V). Additionally, we also observe instances where developers correct
poorly structured names. For example, in the attribute rename chain
setToValue$\rightarrow$groupName$\rightarrow$groupNameTextArea
([30]$\rightarrow$[31]), the original name starts with a verb (i.e., “set”),
which is generally incorrect for an attribute. However, within the chain, the
developer changes the name to start with a noun modifier

TABLE IV: Common part-of-speech patterns associated with the original and final name in the rename chain for each identifier type. | Part-of-Speech
---
Pattern
Count | Percentage
Original Name | Final Name
Class
NM—NM—N | NM—NM—N | 309 | 11.74%
NM—N | NM—N | 216 | 8.20%
NM—NM—NM—N | NM—NM—NM—N | 172 | 6.53%
Other Patterns | 1,936 | 73.53%
Attribute
NM—N | NM—N | 285 | 13.87%
N | N | 231 | 11.24%
NM—NM—N | NM—NM—N | 105 | 5.11%
Other Patterns | 1,434 | 69.78%
Method
V—NM—N | V—NM—N | 401 | 9.65%
V—N | V—N | 273 | 6.57%
V | V | 217 | 5.22%
Other Patterns | 3,266 | 78.57%
Parameter
N | N | 804 | 27.94%
NM—N | NM—N | 500 | 17.37%
N | NM—N | 216 | 7.51%
Other Patterns | 1,358 | 47.19%
Variable
N | N | 1,202 | 32.93%
NPL | N | 617 | 16.90%
NM—N | NM—N | 252 | 6.90%
Other Patterns | 1,579 | 43.26%

A high-level examination of the words making up the name in the identifiers
shows that there are 7,584 instances where the original and final names
contain an equal number of words. Further, our dataset contains 3,901 chains
with identical original and final names. Additionally, we encounter 38 rename
chains where the only difference between the names is a change in the case
(e.g., experimentEngine$\rightarrow$junkEngine$\rightarrow$ExperimentEngine
[32]$\rightarrow$[33]) and seven chains where the difference is a
removal/addition of punctuation(s) (e.g.,
_locator$\rightarrow$loader$\rightarrow$locator [34]$\rightarrow$[35]).

Summary for RQ3. There are numerous instances where even though the words in
an identifier’s name change, the grammatical structure of the initial and last
name in the chain remains the same. Furthermore, developers frequently follow
well-established identifier naming structures when crafting names.

###  IV-D RQ4: To what extent can commit log messages help contextualize the
occurrence of rename chains?

While the prior RQs examine the occurrence and characteristics of rename
chains, we need to understand why developers create these chains. Since
surveying all the developers responsible for creating chains in our dataset is
not feasible, this RQ performs an automated analysis of the commit log
messages associated with commits that form rename chains. We analyze the
commit message from the second rename onwards for each rename chain (i.e., two
or more renames) as the second rename indicates the start of the rename chain.
In our analysis, we perform a topic modeling analysis utilizing the LDA
algorithm, as described in Section III. The results of our LDA analysis yield
three distinct topics associated with these messages – Code Cleanup,
Refactoring, and Bug Fix/Testing.

The Code Cleanup topic includes words such as ‘renaming’, ‘naming’,
‘convention’, ‘cleanup’, and ‘whitespace’, where the renames in the chain are
due to the developer improving code style quality by adhering to standards,
which includes following naming standards. For example, in the chain
myFilenameFilter$\rightarrow$libFilenameFilter$\rightarrow$LibFilenameFilter
([36]$\rightarrow$[37]), the renaming of
libFilenameFilter$\rightarrow$LibFilenameFilter is associated with the message
“Lots of fixes using Checkstyle - Fixed some names to follow conventions…”.

The Refactoring topic includes words such as ‘refactor’, ‘revert’, ‘updated’,
‘changed’, ‘removed, and ‘add’. These commits are associated with developers
updating the code related to the behavior and design of the system. For
example, the commit message of last rename in the chain:
KenyaEmrConfigurator$\rightarrow$KenyaEmrModelConfigurator$\rightarrow$EmrModelConfigurator
([38]$\rightarrow$[39]) is “Major refactor to start process of eventually
moving content manager classes into separate module. For now they are moved to
a different subpackage but remain in the KenyaEMR module until all
dependencies on KenyaEMR are removed”.

Finally, the Bug Fix/Testing topic is associated with the words ‘fix’, ‘bug’,
‘test’, and ‘testcase’. In these instances, the renames are part of either a
bug fix developers perform or are part of unit testing. However, we do notice
that usually, the messages are not very descriptive. For example, the last
message in the chain result$\rightarrow$dependencies$\rightarrow$calc
([40]$\rightarrow$[41]) is “fixed bug with searching for transitive
dependencies + added test for it”.

The topics yielded from our analysis are at a high level. While they show the
actions causing the rename, further insight into why the developer utilized a
specific word for the rename or how the name is related to the action or code
is challenging due to the nature of commit messages.

Summary for RQ4. A topic modeling analysis on the rename chain commit messages
shows the renames are related to Code Cleanup, Refactoring, and Bug
Fix/Testing. However, these topics are at a high-level due to the nature of
commit messages.

##  V Threats To Validity

Even though the projects are limited to Java systems and might not necessarily
generalize to systems written in other languages, these systems follow
software engineering best practices and have been utilized in similar research
on identifier names. Likewise, our methodology utilizes specific tools, such
as RefactoringMiner and the part-of-speech tagger, which pose a risk because
they could not be entirely accurate. These tools, however, are well-known and
state-of-the-art in their respective domain and employed in similar work. Even
though our construction of rename chains is limited to identifiers renamed
within the same class, our results still yield a large number of chains. In
RQ2, we utilize the commit author email to identify individual developers.
While this can introduce threats to the study, manually verifying our
dataset’s large volume of emails is not feasible. Furthermore, as mentioned in
RQ2, emails for identifying developers have been used in prior work.

##  VI Discussion & Conclusion

Interpreting identifier names form the backbone of any code comprehension
task. However, with developers free to craft names using words of their
choosing, they introduce the threat of having names that do not accurately
reflect their behavior (i.e., names of poor quality), which hinders the
maintenance of the system. To correct such poor-quality names, developers
rename them, which can continue throughout the system’s lifetime. In this
study, our analysis of multiple renames applied to a single identifier (i.e.,
rename chain) shows that almost all projects exhibit this phenomenon, with an
average chain size of two renames. Furthermore, we report on characteristics
such as the interval between renames, developers responsible for chain
construction, and grammatical changes. While our findings extend the knowledge
in identifier naming, there are avenues for further research, including
expanding on our RQ4 analysis to study the motivation and contextualization
for the occurrence of rename chains. Below, we discuss how the findings from
our RQs support the community through a series of takeaways.

Takeaway 1 - Reliance on part-of-speech patterns when crafting and evaluating
names. From RQ3, we observe that part-of-speech tags are an efficient means of
studying the semantic updates a name undergoes when renamed. This finding
shows that academia and practitioners should not focus only on the words in a
name but also consider the grammatical structure of the name when crafting and
evaluating identifier names. Additionally, this also presents the
research/vendor community with an opportunity to construct rename
recommendation tools that incorporate the name’s grammatical structure in
addition to the existing features they utilize.

Takeaway 2 - Improvements to name recommendations and appraisal techniques. In
addition to incorporating the grammatical structure, identifier name
recommendation and appraisal techniques should also consider the historical
evolution of an identifier’s name in the evaluation process. Current
techniques usually consider the styling and features present in the version of
the code base under analysis. By examining the historical evolution of the
name, the likelihood of overreliance on outliers is greatly reduced.

Takeaway 3 - Emphasis on the importance of using high-quality names. Academia
should instill in students the importance of having high-quality names in the
source code. For example, our dataset shows the use of abbreviations and
acronyms in forming identifier names. Such tokens are known to impede code
comprehension [4, 42]. Specifically, the initial versions of the attribute
rename chain:
TEMP_TUNNEL_ID$\rightarrow$TUNNEL_ID$\rightarrow$TUNNEL_IDENTIFIER have a
generic word, ‘TEMP’, and an abbreviation, ‘ID’, which are corrected in the
final version of the name. Finally, in addition to using static analysis tools
to detect poor programming practices, such as code and test smells [43, 44],
there should also be a focus on using tools that evaluate the quality of
names, such as linguistic anti-patterns [45, 46].

Takeaway 4 - Challenges with the automated contextualization of rename chains.
Even though our attempts, in RQ 4, at contextualizing the occurrence of rename
chains using the messages in the commit log yielded topics, these topics are
at a high level. They are insufficient in helping us understand how the
changed words in the identifier’s name are related to the code or developer
activity/task. This shows the need for more specialized natural language
processing techniques and also the analysis of other software engineering
artifacts.

###  VI-A Future Work

Our future work in this area includes a human subject study. In this proposed
study, we will work with developers of varying experience and skills to
validate our empirical findings and expand our knowledge on understanding the
rationale for the presence of rename chains in projects. Further, we plan to
discover additional heuristics we can incorporate into appraising and
recommending high-quality identifier names.

## References

  * [1] V. Rajlich and N. Wilde, “The role of concepts in program comprehension,” in Proceedings 10th International Workshop on Program Comprehension, pp. 271–278, 2002.
  * [2] A. Von Mayrhauser and A. M. Vans, “Program comprehension during software maintenance and evolution,” Computer, vol. 28, no. 8, pp. 44–55, 1995\.
  * [3] F. Deissenboeck and M. Pizka, “Concise and consistent naming,” Software Quality Journal, vol. 14, pp. 261–282, Sep 2006.
  * [4] J. Hofmeister, J. Siegmund, and D. V. Holt, “Shorter identifier names take longer to comprehend,” in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 217–227, 2017\.
  * [5] A. Peruma, M. W. Mkaouer, M. J. Decker, and C. D. Newman, “Contextualizing rename decisions using refactorings, commit messages, and data types,” Journal of Systems and Software, vol. 169, p. 110704, 2020.
  * [6] A. Peruma, M. W. Mkaouer, M. J. Decker, and C. D. Newman, An Empirical Investigation of How and Why Developers Rename Identifiers, p. 26–33.  New York, NY, USA: Association for Computing Machinery, 2018.
  * [7] A. Peruma, C. D. Newman, M. W. Mkaouer, A. Ouni, and F. Palomba, An Exploratory Study on the Refactoring of Unit Test Files in Android Applications, p. 350–357.  New York, NY, USA: Association for Computing Machinery, 2020.
  * [8] A. Peruma and C. D. Newman, “Understanding digits in identifier names: An exploratory study,” in 2022 IEEE/ACM 1st International Workshop on Natural Language-Based Software Engineering (NLBSE), pp. 9–16, 2022.
  * [9] V. Arnaoudova, L. M. Eshkevari, M. D. Penta, R. Oliveto, G. Antoniol, and Y.-G. Guéhéneuc, “Repent: Analyzing the nature of identifier renamings,” IEEE Transactions on Software Engineering, vol. 40, no. 5, pp. 502–532, 2014\.
  * [10] A. Peruma, E. Hu, J. Chen, E. A. AlOmar, M. W. Mkaouer, and C. D. Newman, “Using grammar patterns to interpret test method name evolution,” in 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC), pp. 335–346, 2021.
  * [11] M. Allamanis, E. T. Barr, C. Bird, and C. Sutton, “Learning natural coding conventions,” in Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2014.
  * [12] M. Allamanis, E. T. Barr, C. Bird, and C. Sutton, “Suggesting accurate method and class names,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, (New York, NY, USA), pp. 38–49, ACM, 2015.
  * [13] T. Suzuki, K. Sakamoto, F. Ishikawa, and S. Honiden, “An approach for evaluating and suggesting method names using n-gram models,” in Proceedings of the 22nd International Conference on Program Comprehension, ICPC 2014, (New York, NY, USA), p. 271–274, Association for Computing Machinery, 2014.
  * [14] “src/org/getspout/spout/spoutnetserverhandler.java.” https://github.com/spoutcraft/spoutcraftplugin/commit/fe9dbcd.
  * [15] “src/org/getspout/spout/spoutnetserverhandler.java.” https://github.com/spoutcraft/spoutcraftplugin/commit/6aca090.
  * [16] “surefire/report/defaultdirectconsolereporter.java.” https://github.com/apache/maven-surefire/commit/b55a105.
  * [17] “surefire/report/defaultdirectconsolereporter.java.” https://github.com/apache/maven-surefire/commit/6a79127.
  * [18] A. Peruma, M. W. Mkaouer, M. J. Decker, and C. D. Newman, “Contextualizing rename decisions using refactorings and commit messages,” in 2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM), pp. 74–85, 2019.
  * [19] K. Liu, D. Kim, T. F. Bissyandé, T. Kim, K. Kim, A. Koyuncu, S. Kim, and Y. Le Traon, “Learning to spot and refactor inconsistent method names,” in Proceedings of the 40th International Conference on Software Engineering, ICSE 2019, (New York, NY, USA), ACM, 2019.
  * [20] “Dataset.” https://doi.org/10.5281/zenodo.7672274.
  * [21] N. Tsantalis, M. Mansouri, L. M. Eshkevari, D. Mazinanian, and D. Dig, “Accurate and efficient refactoring detection in commit history,” in Proceedings of the 40th International Conference on Software Engineering, ICSE ’18, (New York, NY, USA), p. 483–494, Association for Computing Machinery, 2018.
  * [22] C. D. Newman, M. J. Decker, R. Alsuhaibani, A. Peruma, M. Mkaouer, S. Mohapatra, T. Vishoi, M. Zampieri, T. Sheldon, and E. Hill, “An ensemble approach for annotating source code identifiers with part-of-speech tags,” IEEE Transactions on Software Engineering, pp. 1–1, 2021.
  * [23] K. Toutanova, D. Klein, C. D. Manning, and Y. Singer, “Feature-rich part-of-speech tagging with a cyclic dependency network,” in Proceedings of the 2003 Human Language Technology Conference of the North American Chapter of the Association for Computational Linguistics, pp. 252–259, 2003.
  * [24] M. A. Marcinkiewicz, “Building a large annotated corpus of english: The penn treebank,” Using Large Corpora, vol. 273, 1994.
  * [25] “Scanl - identifier_name_structure_catalogue.” https://github.com/SCANL/identifier_name_structure_catalogue#tagset.
  * [26] D. M. Blei, A. Y. Ng, and M. I. Jordan, “Latent dirichlet allocation,” Journal of machine Learning research, vol. 3, no. Jan, pp. 993–1022, 2003.
  * [27] C. D. Newman, R. S. AlSuhaibani, M. J. Decker, A. Peruma, D. Kaushik, M. W. Mkaouer, and E. Hill, “On the generation, structure, and semantics of grammar patterns in source code identifiers,” Journal of Systems and Software, vol. 170, p. 110740, 2020.
  * [28] “examples/server/thetestservlet.java.” https://github.com/resty-gwt/resty-gwt/commit/01ae3ac.
  * [29] “examples/server/testservlet.java.” https://github.com/resty-gwt/resty-gwt/commit/189f04d.
  * [30] “wizard/add/data/dataintegrationcriteriadialog.java.” https://github.com/gitools/gitools/commit/72eaeb7.
  * [31] “wizard/add/data/dataintegrationcriteriadialog.java.” https://github.com/gitools/gitools/commit/6ed2f62.
  * [32] “src/com/jgaap/backend/junkengine.java.” https://github.com/evllabs/jgaap/commit/1f95c00.
  * [33] “src/com/jgaap/backend/experimentengine.java.” https://github.com/evllabs/jgaap/commit/ccd18a8.
  * [34] “src/main/java/org/scribble2/cli/clijob.java.” https://github.com/scribble/scribble-java/commit/1dbfed2.
  * [35] “src/main/java/org/scribble2/cli/clijob.java.” https://github.com/scribble/scribble-java/commit/ecd98c1.
  * [36] “Lateralgm/org/lateralgm/resources/library/libmanager.java.” https://github.com/ismavatar/lateralgm/commit/c31cd41.
  * [37] “Lots of fixes using checkstyle ·<EMAIL_ADDRESS>https://github.com/ismavatar/lateralgm/commit/c4ab35e.
  * [38] “kenyaemr/kenyaemrmodelconfigurator.java.” https://github.com/i-tech/openmrs-module-kenyaemr/commit/ae9f7aa.
  * [39] “kenyaemr/emrmodelconfigurator.java.” https://github.com/i-tech/openmrs-module-kenyaemr/commit/673931a.
  * [40] “jetbrains/pluginverifier/misc/dependenciescache.java.” https://github.com/jetbrains/intellij-plugin-verifier/commit/ea71d3c.
  * [41] “jetbrains/pluginverifier/misc/dependenciescache.java.” https://github.com/jetbrains/intellij-plugin-verifier/commit/ea71d3c.
  * [42] A. Schankin, A. Berger, D. V. Holt, J. C. Hofmeister, T. Riedel, and M. Beigl, “Descriptive compound identifier names improve source code comprehension,” in 2018 IEEE/ACM 26th International Conference on Program Comprehension (ICPC), pp. 31–3109, 2018.
  * [43] E. Fernandes, J. Oliveira, G. Vale, T. Paiva, and E. Figueiredo, “A review-based comparative study of bad smell detection tools,” in Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering, EASE ’16, (New York, NY, USA), Association for Computing Machinery, 2016.
  * [44] W. Aljedaani, A. Peruma, A. Aljohani, M. Alotaibi, M. W. Mkaouer, A. Ouni, C. D. Newman, A. Ghallab, and S. Ludi, “Test smell detection tools: A systematic mapping study,” in Evaluation and Assessment in Software Engineering, EASE 2021, (New York, NY, USA), p. 170–180, Association for Computing Machinery, 2021.
  * [45] V. Arnaoudova, M. Di Penta, and G. Antoniol, “Linguistic antipatterns: what they are and how developers perceive them,” Empirical Software Engineering, vol. 21, pp. 104–158, Feb 2016.
  * [46] A. Peruma, V. Arnaoudova, and C. D. Newman, “Ideal: An open-source identifier name appraisal tool,” in 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 599–603, 2021.


Copyright for this paper by its authors. Use permitted under Creative Commons
License Attribution 4.0 International (CC BY 4.0).

SEBD 2022: The 30th Italian Symposium on Advanced Database Systems, June
19-22, 2022, Tirrenia (PI), Italy

[ orcid=0000-0002-5734-1274<EMAIL_ADDRESS>] [
orcid=0000-0002-2034-9774<EMAIL_ADDRESS>]

# Extracting Large Scale Spatio-Temporal Descriptions from Social Media

Carlo Bono  Barbara Pernici  Politecnico di Milano, DEIB, Via Giuseppe Ponzio,
34, 20133 Milano, Italia

(2022)

###### Abstract

The ability to track large-scale events as they happen is essential for
understanding them and coordinating reactions in an appropriate and timely
manner. This is true, for example, in emergency management and decision-making
support, where the constraints on both quality and latency of the extracted
information can be stringent. In some contexts, real-time and large-scale
sensor data and forecasts may be available. We are exploring the hypothesis
that this kind of data can be augmented with the ingestion of semi-structured
data sources, like social media. Social media can diffuse valuable knowledge,
such as direct witness or expert opinions, while their noisy nature makes them
not trivial to manage. This knowledge can be used to complement and confirm
other spatio-temporal descriptions of events, highlighting previously unseen
or undervalued aspects. The critical aspects of this investigation, such as
event sensing, multilingualism, selection of visual evidence, and geolocation,
are currently being studied as a foundation for a unified spatio-temporal
representation of multi-modal descriptions. The paper presents, together with
an introduction on the topics, the work done so far on this line of research,
also presenting case studies relevant to the posed challenges, focusing on
emergencies caused by natural disasters.

###### keywords:

social media spatio-temporal event description information mining

##  1 Introduction

The nature of social networks implies an intrinsic distributional variability,
since the topics on social networks usually reflect, to different extents,
events taking place in the world. Some items transport relevant information
about some aspect of reality, usually in the form of unstructured and semi-
structured data. For example, information about a specific event could be made
available using text in some language and/or images and videos, and further
contextualized with tags and conversations, extended with external links, and
enriched with comments and interactions. These different dimensions of social
media posts contain information, explicitly or implicitly, possibly related to
actual events. “Possibly” since separating relevant111Relevant as in
“informative with respect to to some chosen event, kind of event or aspect of
reality” and irrelevant information is usually cumbersome, both because of
input data quality and volume. Since we aim at extracting descriptions of
large-scale events along the dimensions of space and time, we mainly focus on
two operational aspects: the ability to automatically detect whether a certain
event is actually ongoing, and the ability to extract quantitative, actionable
measures as the event unfolds, possibly in an adaptive fashion. The former is
meant to be used as a trigger for preempting data collection tasks. The latter
has to be compared and complemented with other layers, such as sensor or
forecast data, in order to enhance the understanding of reality. Both aspects
are affected by the variability of the social media data distribution over
space and time, and both can exploit the same variability.

The remainder of this work is structured as follows. In the next session, the
main challenges and topics in the literature are reviewed. Section 3
illustrates the investigations conducted so far on these topics. Section 4
combines these results in an application customized for flood events. Finally,
Section 5 sketches future medium-term research directions.

##  2 Related work

The opportunities and challenges for using social media in emergency
management have been trending topics over the last years. Large-scale
emergencies are not trivial to tackle with automated and practical tools. We
focus on emergencies since there is an essential value, as well as they pose
complex questions to be studied. The papers [1, 2] highlight recent
opportunities, challenges, applications and directions for the use of social
media data for emergency management at large. Vertical studies for the use of
social media for specific events have been performed, such as [3] for
earthquake events and [4, 5] for the case of flood events. Techniques for
automatic image filtering on social network data, mainly using deep learning,
have been studied in the field of emergency and social sensing in [6, 7].

Methodologies and resources to analyze social media posts in multiple
languages are also essential, as discussed in [8] for lexicon building, and in
[9] for an adaptive, cross-source approach to social media crawling. How and
to which extent social media can be integrated into production-grade emergency
management systems has been studied in [10] and [11]. Some of the current work
builds on past experience with emergencies, as documented in [12].

Although many studies explicitly address detection, filtering, geolocation and
multilinguality support, some limitations exist. Production-level requirements
are hardly met for many kind of events. Multi-modal approaches are sometimes
investigated in literature, but not widely adopted and usually limited to one
of the tasks. The same holds true for data fusion approaches. Our
investigation aims at designing an end-to-end framework for automatically
deriving event characterizations, taking advantage of multi-modal and multi-
source approaches in order to solve these challenges. Benchmarking and
comparison with existing solutions will be performed on publicly available
datasets and self-produced ones.

##  3 Issues and methods

###  3.1 Event detection and adaptation

Monitoring regions of the world for classes of events is one of the possible
entry points for social media data collection and processing. Some notable
sources of information can dispatch alerts and forecasts, as it happens with
GDACS222The Global Disaster Alert and Coordination System, started in 2004, is
a joint initiative of the United Nations Office for the Coordination of
Humanitarian Affairs (UN OCHA) and the European Commission (EC). and
GloFAS333The Global Flood Awareness System is a component of the Copernicus
Emergency Management Service (CEMS) that delivers global hydrological
forecasts to registered users..

In this context, we study both timeliness and geographical precision of
information derived from social media, in particular tweets, as we analyze it
compared to information available in authoritative sources. Not all events are
covered with the same timeliness, so for large scale events, we are using
posterior validated data to understand to which extent social media can
support already available data, such as forecast and sensor data, as a
detection mechanism.

As a first step, the use of dictionaries of query terms for social sensing is
being evaluated. For each of the dictionary terms, the time series of the term
usage over a recent time window can be obtained. This signal is then used to
estimate if an event of interest is ongoing or not. A first exploration of
this methodology can be found in [13], in which we focused on searching
Twitter in many possible languages starting from a limited set of seed search
keywords. We are studying how to leverage available ground truth in order to
automatically build language-tailored resources. The current focus is on
building language-centered dictionaries with a data-centered
approach444Leveraging language models, word embeddings and external data
sources, minimizing human intervention and taking advantage of the temporal
correlation between words and events. Feature windows built with these
dictionaries are then fed to a supervised classifier, such as a CNN, and
evaluated in a leave-one-event-out fashion. Our preliminary assessment shows
that a low precision (<50%) and a good recall (~80%) triggering system can be
achieved, with almost no human intervention. This result is achieved with
negligible processing effort, and a comfortable request resolution.555One
request per second https://developer.twitter.com/en/docs/twitter-api/rate-
limits

Figure 1: Occurrence of "landslide", compared with flood events in Nepal
reported by GDACS

Detecting an event onset is only the first step towards awareness. Moreover,
an efficient detection mechanism provides a precious byproduct: broad matching
keywords related to events of interest. These, in principle, enhance the
recall of the data collection. But as broad as they can be, two issues should
be considered. On one side, unpredictable descriptors, event-specific
qualities and linguistic variations are bound to happen. One significant
example is given by location names, which are not usually constant across
events. On the other side, good "general purpose" predictive features do not
guarantee to match relevant contents only. In light of this consideration,
adaptive methods of data collection should be prioritized. Adaptability is
aimed at controlling the specificity of an event, together with its evolution
over space and time. An example of an approach that is both automated and
adaptive is given by [9], focusing on identifying variable search keywords
over time.

###  3.2 Understanding and filtering semi-structured contents

Methods and tools that extract structured information from social media are
the main focus of this line of research. Among the general questions that can
be posed, we include questions about the category of posts, as in “is this
post about <x>?”. These questions can be usually translated to supervised
classification tasks. The questions being asked could be related to some
specific semantic of the content, as in “is there a <y> in this image?”. Some
of these questions could still be mapped to classifications tasks, while some
others relate to detection or segmentation tasks. A systematic approach for
answering this kind of questions has been proposed in [7], developing the
VisualCit666http://visualcit.polimi.it:7778/ image processing toolkit, aimed
at extracting indicators about emergency events. Here, image classification
and object detection are usually achieved through the use of deep neural
networks, both with off-the-shelf solutions and custom trained networks. In
this way, specific queries can be posed to social media data, describing
specific contents or situations, such as “two or more persons” or “a flood
event”. In addition, the ability to leverage user feedback to adjust
classifiers is also a topic of interest. Pre-processing actions such as
removing near-duplicates and filtering non-photographic material are also
supported.

Figure 2: VisualCit interface for pipeline sketching

Text classification techniques, as well as a fused representation of textual,
image, and metadata, are areas of interest, although so far they have been
inspected only preliminarily. The primary goal would be to track known
attributes of a situation, such as phases or topics, in order to characterize
it. Since in this case the inputs are formulated in natural language, special
attention is being paid to multilingualism. Multilingualism can be supported
with the use and the development of language-independent tools and
representations, such as language-agnostic embeddings, or approaches that
support a relevant set of languages.

Characterization of social media posts can be almost naturally attached to a
temporal dimension. As a first approximation, since the extracted information
augments the stream of published media, it is reasonable to assume that the
information relates to near-realtime circumstances. A more pressing issue is
the one about the spatial dimension of the contents. If the contents are not
natively geolocated, as it usually happens777For example, for privacy issues.,
the location of the posts should be inferred. This is usually a harder problem
and faceted, since the location of the author could differ from the
location(s) related to the contents, or the hints for understanding the
location could be flimsy. A comprehensive approach to social media geolocation
has been proposed in the CIME system [14], which is currently being used by
VisualCit. CIME disambiguates candidate locations using
Nominatim888https://nominatim.openstreetmap.org/. The disambiguation algorithm
considers candidate locations, their distances, and their ranks in the OSM
administrative hierarchy. CIME was exploited in the E2mC project [12] to
support rapid mapping activities within Copernicus Emergency Management
Services. Extracted geolocations can be further filtered with known geometries
(e.g., countries being monitored) and/or density-based approaches, also
leveraging in-post and between-post relationships.

###  3.3 Building and enhancing pipelines

Comprehensive and quick reaction to large scale events requires a systematic
approach to processing. Functionalities implemented so far are available with
a service-based paradigm. Composite functionalities can be instantiated as a
processing pipeline, using a straightforward configuration file, indicating
components to be invoked and respective parameters, such as confidence
thresholds. Of course, as it happens for the events themselves, the
configuration of a pipeline is not always predictable. Data distributions,
quality constraints and workforce availability are likely to change over time.
With this fact in mind, we evaluated an iterative approach to provide
suggestions to designers of data preprocessing pipelines. Iterations with user
feedback are meant to rapidly achieve the desired goals, reflecting
application needs and limitations and understanding the quality of the output.
The designer is provided with an informative environment in which components,
constraints, and parameters can be evaluated. Components typically consist of
data filtering or augmentation modules, representing implementations of the
tasks introduced in 3.2. Constraints are usually expressed on processing
quality, efficiency and cost. Figure 3 shows an example dashboard in which the
effect of the pipeline components on the final output is visualized
interactively. The effect is measured in terms of precision, recall and number
of filtered items. The evaluation is performed using a validated sample
dataset, provided during the design process.

(a) Is this a photo? (b) Are there two or more persons? (c) Is this a public
place?

Figure 3: Precision, recall and reduction rate responses to confidence
threshold, on an example pipeline

Processing posts with tailored pipelines dramatically reduces the number of
posts. Depending on application needs, the number of items that are filtered
out and the quality of the output can be balanced. Suggestions about possible
improvements are provided, such as modifications to the configuration of the
pipeline, based on historical or current evidence. Suggestions could also
concern the execution order of the pipeline, for performance optimization. We
showed that, in some test cases, an optimized configuration could lead to
around 33% of the original execution time, without affecting the output.

##  4 Case studies

As case studies, we exploited, extended and adapted available tools to assess
their reliability when used as a triggering and analysis system for large
scale disaster events. We applied a combination of the proposed methodologies
to two flood events that occurred in 2021 in Thailand (September) and Nepal
(June and July). The two events were selected since the United Nations
Satellite Centre (UNOSAT) supported both activations in Nepal and Thailand
with satellite-derived maps and AI-based flood detection analysis. In both
case studies, we used Twitter as a data source.

Initial evidence suggested the need for language-specific approaches rather
than focusing on contents written in English. Regarding event detection, the
experimentation was started with a limited amount of words. The word count
signal over time proved to be sufficient to detect the two events within a
reasonable time frame. Using small dictionaries is less sensitive to noise but
poses a number of limitations, which have been discussed in subsection 3.1. A
pipeline consisting of the following tasks has been run in order to select
relevant data:

  1. 1.

Remove duplicated images and similar images.

  2. 2.

Remove non-photos, such as drawings, screenshots and computer-generated
images.

  3. 3.

Remove not-safe-for-work images999“Not suitable for viewing at most places of
employment”, according to the Merriam-Webster online dictionary..

  4. 4.

Geolocate posts using CIME.

Processing the posts with such a pipeline reduced the amount of data by orders
of magnitude. The output, aggregated by administrative region, was compared to
official impact estimates (Fig. 4 and 5) shows promising yet improvable
results. We were able to process and geolocate images at a rate of roughly
10,000 items per hour, on a single server machine. This proved to be
sufficient for real-time event monitoring.

Data | Count
---|---
All tweets, September 26-27 | 4’145’447
No retweets | 66’868
Containing images | 6’292
Native Twitter locations | 227
Overall images | 8’774
Passed VisualCit filters | 3’056
Places geolocated by CIME | 1’671
Table 1: Dataset cardinality through processing, Thailand case study

(a) Removed items

(b) Kept items

Figure 4: Example images for (a) items being removed by the pipeline, and (b)
items being kept

(a) Geolocations / inhabitants ratio by region, normalized by population

(b) Affected persons by region at September, 28th (source: ReliefWeb)

Figure 5: Comparing pipeline output and preliminary impact assessment,
Thailand case study [13]

##  5 Future work

The current work in progress is aimed at detection methods, components for
data extraction, and process design support. Together, these elements can be
leveraged to project the streams of raw data onto spatio-temporal coordinates,
in order to get a suitable and actionable description of reality. So far,
official, sensor and forecast data have been used as a reference for
evaluating the quality of the approaches. Also, they could be fused together,
in order to build a multi-faceted view of reality. This is the guiding goal
for future work on the topic. At the same time, since social media contents
are highly multi-modal by definition, we want to explore how different
dimensions and aggregations of social media data can be combined in multi-
modal representations in order to better fit the required functionalities,
such as classification tasks.

#### Acknowledgements

This work was funded by the EU H2020 project Crowd4SDG “Citizen Science for
Monitoring Climate Impacts and Achieving Climate Resilience”, #872944.

## References

  * Imran et al. [2020] M. Imran, F. Ofli, D. Caragea, A. Torralba,  Using AI and social media multimodal content for disaster response and management: Opportunities, challenges, and future directions,  Information Processing & Management 57 (2020) 102261.
  * Lorini et al. [2021] V. Lorini, C. Castillo, S. Peterson, P. Rufolo, H. Purohit, D. Pajarito, J. P. de Albuquerque, C. Buntain,  Social media for emergency management: Opportunities and challenges at the intersection of research and practice,  in: 18th International Conference on Information Systems for Crisis Response and Management, 2021, pp. 772–777.
  * Sakaki et al. [2013] T. Sakaki, M. Okazaki, Y. Matsuo,  Tweet analysis for real-time event detection and earthquake reporting system development,  IEEE TKDE 25 (2013) 919–931.
  * Fohringer et al. [2015] J. Fohringer, D. Dransch, H. Kreibich, K. Schröter,  Social media as an information source for rapid flood inundation mapping,  Natural Hazards and Earth System Sciences 15 (2015) 2725–2738.
  * Shoyama et al. [2021] K. Shoyama, Q. Cui, M. Hanashimaa, H. Sano, Y. Usuda,  Emergency flood detection using multiple information sources: Integrated analysis of natural hazard monitoring and social media data,  Science of the Total Environment 767 (2021) 1–11.
  * Nguyen et al. [2017] D. T. Nguyen, F. Alam, F. Ofli, M. Imran,  Automatic image filtering on social networks using deep learning and perceptual hashing during crises,  in: Proc. 14th ISCRAM Conf. – Albi, France, 2017\.
  * Negri et al. [2021] V. Negri, D. Scuratti, S. Agresti, D. Rooein, G. Scalia, A. R. Shankar, J. L. Fernandez-Marquez, M. J. Carman, B. Pernici,  Image-based social sensing: Combining AI and the crowd to mine policy-adherence indicators from twitter,  in: 43rd IEEE/ACM Intl. Conf. on Sw. Eng. Track Software Engineering in Society, ICSE (SEIS), Madrid, Spain, IEEE, 2021, pp. 92–101.
  * Olteanu et al. [2014] A. Olteanu, C. Castillo, F. Diaz, S. Vieweg,  Crisislex: A lexicon for collecting and filtering microblogged communications in crises,  Proceedings of the International AAAI Conference on Web and Social Media 8 (2014) 376–385.
  * Autelitano et al. [2019] A. Autelitano, B. Pernici, G. Scalia,  Spatio-temporal mining of keywords for social media cross-social crawling of emergency events,  GeoInformatica 23 (2019) 425–447.
  * Stollberg and De Groeve [2012] B. Stollberg, T. De Groeve,  The use of social media within the global disaster alert and coordination system (GDACS),  in: Proceedings of the 21st International Conference on World Wide Web, 2012, pp. 703–706.
  * Lorini et al. [2020] V. Lorini, C. Castillo, D. Nappo, F. Dottori, P. Salamon,  Social media alerts can improve, but not replace hydrological models for forecasting floods,  in: 2020 IEEE/WIC/ACM Intl. Joint Conf. on Web Intelligence and Intelligent Agent Technology (WI-IAT), IEEE, 2020, pp. 351–356.
  * Havas et al. [2017] C. Havas, B. Resch, C. Francalanci, B. Pernici, G. Scalia, J. L. Fernandez-Marquez, T. Van Achte, G. Zeug, M. R. R. Mondardini, D. Grandoni, et al.,  E2mC: Improving emergency management service practice through social media and crowdsourcing analysis in near real time,  Sensors 17 (2017) 2766.
  * Bono et al. [2022] C. Bono, B. Pernici, J. L. Fernandez-Marquez, A. R. Shankar, M. O. Mülâyim, E. Nemni,  Triggercit: Early flood alerting using twitter and geolocation–a comparison with alternative sources,  arXiv preprint arXiv:2202.12014, accepted for presentation at ISCRAM’22 (2022).
  * Scalia et al. [2021] G. Scalia, C. Francalanci, B. Pernici,  Cime: Context-aware geolocation of emergency-related posts,  GeoInformatica (2021) 1–33.


* [Mor01] S. Morita  “Geometry of Differential Forms” 201, Iwanami Series in Modern Mathematics  American Mathematical Society, 2001
  * [Nak96] M. Nakahara  “Geometry, Topology and Physics”  Institute of Physics Publishing, 1996
  * [Pan98] Martin Panák  “Natural operators on the bundle of Cartan connections”  In _Proceedings of the Conference Differential Geometry and Applications, Brno_ , 1998, pp. 285–292
  * [PW17] Marcella Palese and Ekkehart Winterroth  “Topological obstructions in Lagrangian field theories, with an application to 3D Chern–Simons gauge theory”  In _Journal of Mathematical Physics_ 58.2 AIP Publishing, 2017, pp. 023502  DOI: 10.1063/1.4975336
  * [RSW89] T. R. Ramadas, I. M. Singer and J. Weitsman  “Some comments on Chern-Simons gauge theory”  In _Communications in Mathematical Physics_ 126.2 Springer ScienceBusiness Media LLC, 1989, pp. 409–420  DOI: 10.1007/bf02125132
  * [Sau89] D. J. Saunders  “The Geometry of Jet Bundles”  Cambridge University Press, 1989
  * [Sha97] R.W. Sharpe  “Differential geometry: Cartan’s generalization of Klein’s Erlangen program”, Graduate texts in mathematics  Springer, 1997  URL: http://books.google.com.ar/books?id=poV6SSopE9QC
  * [Ste99] Norman Steenrod  “The topology of fibre bundles”  Princeton, N.J: Princeton University Press, 1999
  * [Tej04] Carlos Tejero Prieto  “Variational formulation of Chern–Simons theory for arbitrary Lie groups”  In _Journal of Geometry and Physics_ 50.1-4 Elsevier BV, 2004, pp. 138–161  DOI: 10.1016/j.geomphys.2003.11.005
  * [Wis+09] Derek K Wise  “Symmetric space Cartan connections and gravity in three and four dimensions”  In _Symmetry, Integrability and Geometry: Methods and Applications_ 5 SIGMA. Symmetry, IntegrabilityGeometry: MethodsApplications, 2009, pp. 080
  * [Wis10] Derek K Wise  “MacDowell–Mansouri gravity and Cartan geometry”  In _Classical and Quantum Gravity_ 27.15 IOP Publishing, 2010, pp. 155010  DOI: 10.1088/0264-9381/27/15/155010
  * [Wit88] Edward Witten  “$2+1$-dimensional gravity as an exactly soluble system”  In _Nuclear Phys. B_ 311.1, 1988, pp. 46–78  DOI: 10.1016/0550-3213(88)90143-5
  * [Wit88a] Edward Witten  “Topological quantum field theory”  In _Communications in Mathematical Physics_ 117.3, 1988, pp. 353–386  DOI: 10.1007/BF01223371