# Screening Crossref for integrity issues: Massive and longitudinal mining of publication metadata

Jules Di Scala, Guillaume Cabanac, Ophélie Fraisier-Vannier, Ronan Tournier

► To cite this version:

Jules Di Scala, Guillaume Cabanac, Ophélie Fraisier-Vannier, Ronan Tournier. Screening Crossref for integrity issues: Massive and longitudinal mining of publication metadata. 2025 ACM/IEEE Joint Conference on Digital Libraries (JCDL), Dec 2025, Dekalb, United States. pp.119-128, 10.1109/jcdl67857.2025.00023 . hal-05497878

HAL Id: hal-05497878

https://ut3-toulouseinp.hal.science/hal-05497878v1

Submitted on 6 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Screening Crossref for integrity issues: Massive and longitudinal mining of publication metadata

Jules di Scala
IRIT UMR 5505 CNRS
Université de Toulouse
Toulouse, France
jules.di-scala@irit.fr
0009-0005-3460-0535

Guillaume Cabanac
IRIT UMR 5505 CNRS
Université de Toulouse
Toulouse, France
Institut Universitaire de France (IUF)
Paris, France
guillaume.cabanac@irit.fr
0000-0003-3060-6241

Ophélie Fraisier-Vannier
IRIT UMR 5505 CNRS
Université de Toulouse
Toulouse, France
ophelie.fraisier-vannier@irit.fr
0000-0003-2974-5308

Ronan Tournier
IRIT UMR 5505 CNRS
Université Toulouse 1 Capitole
Toulouse, France
ronan.tournier@irit.fr
0000-0001-9978-8616

**Abstract**—Scientific articles are usually associated with a Digital Object Identifier (DOI). Most publishers request DOIs from Crossref, the largest registration agency that has minted 173 million DOIs to date. The Crossref database stores the metadata of each scholarly work, including its title, authors, as well as references found in the bibliography. Since 2018, Crossref releases monthly dumps of its database amounting to 64 TB in JSON format. Recent integrity issues warrant a complete audit with longitudinal analysis of the Crossref archives. However, auditing is challenging due to the evolving nature of these massive metadata. We introduce an approach to store the complete archives that tracks the history of modifications efficiently. The longitudinal screening of the metadata is illustrated with two indicators designed to detect potential misconducts. We discovered and report two such anomalies involving suspect authors/publishers seemingly gaming citation metrics as well as a previously documented case of fraud involving a journal and its authors. The code is released for reproducibility and to encourage other researchers and Crossref to perform further analyses.

**Index Terms**—Scholarly publication, Metadata, Crossref, Research Integrity, Quality Insurance, Data Versioning

## I. INTRODUCTION

The increased attention on publication and citation-based metrics contribute to a *publish or perish* atmosphere. This encourages some authors and editors to engage in questionable research practices [1] as these metrics are fairly easy to manipulate [2–4]. And yet, more than 60% of institutions evaluate researchers based on their citation counts and rely mainly on Google Scholar [5].

The way metrics are computed leave a wide array of possibilities to game author citation counts and *h*-index, as well as journal impact factors [6]. All along the knowledge production process, various roles are affected. Editors can game metrics without even the authors’ knowledge [7, 8] or by pressuring authors during peer review [9]. Publishers can engage in citation cartels to increase their journal impact factors [10]. Authors can act similarly to increase their individual citation counts [11]. A simple way of increasing one’s own citation count is by self-citing. Although this practice is expected to some extent [12], excessive and irrelevant self-citation have

also been identified and documented [13]. Reviewers can coerce authors to cite their work [14, 15].

Today, scientometric platforms compute citation metrics using two approaches. Google Scholar relies on several resources, from PDFs parsing, to crawlers and known databases<fnref n="1" />. In contrast, most of the new scientometric platforms, like OpenAlex [16] and Dimensions [17], rely primarily on Crossref, the principal<fnref n="2" /> Digital Object Identifier (DOI) registration agency. In fact, most scholars reading this paper have publications registered by Crossref: it serves more than 20 000 organizations, including both major and small publishers. Publishers, as subscribing members of Crossref, push and update metadata for their scientific-related objects—most being documents like articles.<fnref n="3" /> Articles metadata include the associated DOI, a list of authors, a list of references (these from the bibliography, hopefully containing a DOI), an abstract, a title, the article’s publication date, and much more.<fnref n="4" />

Crossref entrusts its members with the maintenance and the accuracy of metadata they push as Crossref records. Members are asked to update their Crossref records when changes occur<fnref n="5" />—for instance, if an article is retracted, or when a correction is required, or when the document type changes (for example when a preprint becomes a published article, as illustrated in Figure 3). Therefore, Crossref does not validate the metadata they receive and store. Third parties access the Crossref records through a rate-limited API<fnref n="6" /> or via monthly-released public data dumps.<fnref n="7" /> Due to their volume, these dumps are hard to mine. Indeed, Crossref stores and provides :

* Over 170-million records including more than 110-million journal articles.<fnref n="8" />

<footnote n="1">¹https://scholar.google.com/intl/en/scholar/inclusion.html</footnote>

<footnote n="2">²https://www.doi.org/the-community/existing-registration-agencies/</footnote>

<footnote n="3">³https://www.crossref.org/documentation/schema-library/required-recom
mended-elements/</footnote>

<footnote n="4">⁴See https://i4oc.org and https://i4oa.org for more information.</footnote>

<footnote n="5">⁵https://www.crossref.org/documentation/register-maintain-records/maintain
ing-your-metadata/</footnote>

<footnote n="6">⁶https://www.crossref.org/documentation/retrieve-metadata/rest-api/</footnote>

<footnote n="7">⁷https://api.crossref.org/snapshots/monthly</footnote>

<footnote n="8">⁸https://www.crossref.org/06members/53status.html</footnote>
* Over 1.8 billion citation links have been identified according to the bibliographies in the records. Over half of the references include a DOI, which has been asserted either by the publisher or by Crossref (this later information being available in the records).

* Monthly data dumps released between 2018-04 and 2025-07: each of the 88 files is a compressed tar.gz archive with a size varying from 46 to 231 GB. The dumps represent 12 TB when compressed and 64 TB when uncompressed. The most recent dump contains more than 31 000 JSON files, each containing 5000 records.

Crossref records are subsequently processed by scientific platforms to compute quantitative and qualitative metrics, such as citation counts and lists of the highly cited researchers. These metrics need to be accurate as researchers' evaluation usually depends on their scientific performance. However, scientific platforms are sensitive to errors stemming from their source datasets, Crossref being a major one. Recent research revealed quality issues due to potential citation gaming: 'sneaked references' reflects the presence of references in the metadata although being absent from the article's bibliography [8]. Such undue references were added by the editors at metadata deposit time to increase their citation counts. Scientific platforms ingesting Crossref data propagate the errors that corrupt citation counts (Figure 1).

We wondered about any other cases of citation or authorship manipulations. To this end, one must frequently mine the Crossref metadata in order to measure indicators over time and identify anomalies. Some anomalies relate to fallacious record updates; it is thus mandatory to track record changes. In this context, the storage of Crossref metadata can be approached as a Slowly Changing Dimensions (SCD) problem [18], where updates are happening monthly with the release of each new dump. Since Crossref provides full monthly snapshots, rather than incremental updates, this problem can be reduced to a non-overlapping validity periods SCD problem [19].

For mining purposes, Crossref provides the doi2SQLite tool<fnref n="9" /> that loads a JSON monthly dump into a relational database. In our view, this approach has three limitations. First, the tool produces a separate database for each loaded monthly dump, making it unfeasible to perform longitudinal mining over multiple months. Second, the resulting database includes unstructured bibliography references which requires additional processing time, making the screening for sneaked references unfeasible at large scale. Third, the resulting database is created with SQLite and other database vendors are more suited to handle terabytes of data with parallel processing on dedicated servers.

Each Crossref record bears its date of deposit and the date of last modification, if applicable. Mining one dump provides the latest version of a record but prevents one from listing the sequence of modifications that it underwent. This limitation justifies the work introduced in this paper: To longitudinally

mine Crossref records one needs to account for all dumps simultaneously. Next, we present a storage-efficient method for mining these massive data with all changes tracked.

## II. CONTRIBUTION: LONGITUDINAL MINING OF VERSIONED CROSSREF METADATA

We designed this method to be easy to reuse. We chose to store and exploit Crossref dumps with a relational database and provide associated scripts. We then tested our model by conducting analyses on Crossref data.

### A. Design: Conceptual Level

The conceptual contribution of this paper is twofold. First, we present the AllDumps-1DB method: a database with its relational model to store and exploit Crossref data and an algorithm to load the dumps. Second, we detail two anomaly detection metrics.

1) Relational Model: Our relational model (Figure 2) consists of three relations – primary key attributes (PK) are underlined:

* Articles (DOI, validFrom, validTo, type, venue, published, created, title)

* Authors (DOI, author, validFrom, validTo)

* References (DOI, reference, validFrom, validTo, count, selfCitation, articleToArticle, assertedBy)

These data represent Articles that are linked to Authors, and these articles also contain References. Articles stores the main attributes of Crossref records, which represent any kind of scientific production, encompassing journal articles, papers in conference proceedings, book chapters, datasets, and so on. Each tuple corresponds to the state of a record (identified by its DOI) over a period delimited by [validFrom, validTo]. For all of the tuples in these relations, validFrom indicates the dump from which a tuple becomes valid, and validTo corresponds to the dump that invalidates it. More concretely, updated records add new tuples with validity periods in the database instead of erasing the previous ones (type 2 SCD system [18]). Both validFrom and validTo attributes are numeric identifiers of a dump (e.g., 202506 stands for June 2025 and nil denotes the record is currently valid). Validity periods are stored as integer year-month values (recommended in [20]), reflecting the fact that the temporal granularity of our dataset is strictly monthly. According to our model, there should never be overlapping periods for a same database record.

**Example.** The following tuples have the same DOI but different valid periods:

* (10.x/doi1, 202501, 202504, "pre-print",...)

* (10.x/doi1, 202504, nil, "journal-article",...)

The preprint identified by the DOI 10.x/doi1 was recorded in January 2025, and became a journal article in April 2025 (included). There is only one Crossref record identified by 10.x/doi1, but it has two different states over time.

<footnote n="9">⁹See https://www.crossref.org/learning/public-data-file/ and https://gitlab.c om/crossref/labs/dois2sqlite</footnote>
<figure><img src="image_2.png" /><figcaption>Fig. 1. Illustration of sneaked references and their impact on citation-based metrics and scholars.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Logical diagram of our database uses the relational model where relations contain attributes and primary keys grouped in the PK blocks.</figcaption></figure>

Authors stores the authorship relationships between a scientific production (identified by its DOI) and an author (name and surname). References stores the citation links. DOI is the DOI of the citing article, while reference is the DOI of the cited article. Only references containing a DOI are kept in our database. assertedBy indicates who validated the cited DOI: the publisher or Crossref.<fnref n="10" /> count is the number of times the reference appears in the bibliography of the article identified by DOI (which normally should be one).

2) Loading Algorithm: Articles, Authors and References tuples are read according to Algorithm 1, where:

* `READ ARTICLE(record)` generates a tuple for the Articles relation, from a record.

* `READ_AND_DISAMB_AUT(record)` generates tuples for the Authors relation, for each author in the record.

The process to disambiguate author names is described in subsection II-B.

* `READ_AND_FILTER_REF(record)` generates tuples for the References relation, for each reference having a DOI in the record's references.

Algorithms 2 to 4 describe procedures `INSERT_OR_UP-DATE ART`, `INSERT_OR_UPDATE_AUT` and `INSERT_OR_UP-DATE_REF`.

**Algorithm 1** Rough processing of a dump

Input: `data_dump` ▷ one Crossref tar.gz archive
Input: `dd` ▷ dump date (e.g., 202504 for Apr 2025)
1: `article_tuple`s ← empty list
2: `author_tuple`s ← empty list
3: `ref_tuple`s ← empty list
4: **for** all `rec` ∈ `READ_AND_EXTRACT(data_dump)` **do**
5:     append `READ ARTICLE(rec)` to `article_tuple`s
6:     append elements of `READ_AND_DISAMB_AUT(rec)` to `author_tuple`s
7:     append elements of `READ_AND_FILTER_REF(rec)` to `reference_tuple`s
8: **end for**
9: `INSERT_OR_UPDATE ART(article_tuple`s, `dd)`
10: `INSERT_OR_UPDATE_AUT(author_tuple`s, `dd)`
11: `INSERT_OR_UPDATE_REF(ref_tuple`s, `dd)`

Our method requires that the Crossref dumps are inserted in a chronological order. It is expected to be run once with the available dumps to date and then monthly, when Crossref releases the latest dump. Let us distinguish the following 3 cases when inserting or updating an article *a* with Algorithm 2 while reading a new dump (Figure 3):

* Case 1. This dump is the first to be inserted. In this case, we insert *a* in Articles.

* Case 2. Dumps were inserted and an article with the same DOI but different properties is already valid in

<footnote n="10">¹⁰https://www.crossref.org/documentation/cited-by/cited-by-participation/</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 3. Illustrating the three cases when inserting an article in *Articles*.</figcaption></figure>

Articles. In this case, we invalidate the article currently present in *Articles* and we insert *a*.

* Case 3. Dumps were inserted and the exact same article is already valid in *Articles*. Nothing to do.

DOIs are persistent identifiers<fnref n="11" /> and Crossref does not allow record deletions even when articles are retracted. Our algorithm aligns with this policy and never deletes records.

For Algorithms 2 to 4 we define the following procedures and functions:

* `INSERT tuplex, relation, validFrom, validTo`: Adds a tuple to the relation (*Articles*, *Authors*, or *References*), valid from `validFrom` to `validTo` (format: YYYYMM). If the tuple is currently valid, we set `validTo` to `nil`.

* `INVALIDATE tuplex, relation, dump_date`: Invalidates the valid tuples having the same primary key (PK) in the relation by setting its `validTo` value to the new `dump_date` (the dump that invalidates this tuple).

* `IS_VALID(tuplex, relation)`: Returns `True` if a tuple with the same DOI, or DOI-Author, or DOI-Reference is currently valid and present in the relation. This function compares the `deposited` field (the date when it was updated for the last time) of the record with the last `deposited` value of the record in the last inserted dump. The rationale here is that it is useless to update a record that has not been updated since the last insertion.

* `IS_EXACTLY_IN(tuplex, relation)`: Returns `True` when the tuple exists (all attributes identical except validity period bounds: `validFrom` and `validTo`) and is valid in the relation.

* `SELECT_VALID(relation)`: Returns all valid tuples in the relation.

In Algorithm 3 we distinguish 3 cases when inserting or updating an authorship tuple *a* = (*DOI*, *authorName*) with `INSERT_OR_UPDATE_AUT` while reading a new dump:

* Case 1: This dump is the first to be inserted; we insert *a* in *Authors*.

* Case 2: Dumps were inserted but *a* is not currently in *Authors*; we insert *a* in *Authors*.

### Algorithm 2 INSERT_OR_UPDATEassen

**Input:** tuples ▷ the list of article tuples to insert
**Input:** dd ▷ number representing the inserted dump's date
1: **for** all *tuple* ∈ tuples **do**
2:   **if** not `IS_VALID(*tuple*, *Articles*)` **then**
3:     `INSERT(*tuple*, *Articles*, *dd*, *nil*)
4:     **else if** not `IS_EXACTLY_IN(*tuple*, *Articles*)` **then**
5:       `INVALIDATE(*tuple*, *Articles*, *dd*)
6:       `INSERT(*tuple*, *Articles*, *dd*, *nil*)
7:   **end if**
8: **end for**

<figure><img src="image_5.png" /><figcaption>Fig. 4. Illustrating the modification of an author's name in *Authors*</figcaption></figure>

* Case 3: Dumps were inserted and the exact tuple is already valid in *Authors*. Nothing to do.

Once all authorship tuples are inserted, we invalidate every tuple in *Authors* that is not in the inserted dump (it means the author has been removed from the record). When a Crossref member updates an author name in a record, Case 2 and old tuple invalidation occur because the old name is removed and a new name is added (Figure 4).

### Algorithm 3 INSERT_OR_UPDATE_AUT

**Input:** tuples ▷ the list of article-author tuples to insert
**Input:** dd ▷ number representing the inserted dump's date
1: **for** all *t* ∈ tuples **do**
2:   **if** not `IS_VALID(*t*, *Authors*)` **then**
3:     `INSERT(*t*, *Authors*, *dd*, *nil*)
4:   **end if**
5: **end for**
6: **for** all *t* ∈ `SELECT_VALID(*Authors*)` **do**
7:   **if** *t* ∉ tuples **then**
8:     `INVALIDATE(*t*, *Authors*, *dd*) ▷ removing authors
9:   **end if**
10: **end for**

In Algorithm 4 we distinguish 4 cases when inserting or updating an reference tuple *r* = (*Citing_DOI*, *Cited_DOI*) with `INSERT_OR_UPDATE_AUT` while reading a new dump:

* Case 1: This dump is the first to be inserted; we insert *r* in *References*.

* Case 2: Dumps were inserted but *r* is not currently in *References*; we insert *r* in *References*.

* Case 3: Dumps were inserted, *r* is currently valid in *References*, but with different parameters (for instance, *Count*); we invalidate the current tuple in *References* and we insert *r* in *References*.

<footnote n="11">¹¹https://www.crossref.org/documentation/register-maintain-records/creatin g-and-managing-dois/</footnote>
* Case 4: Dumps were inserted and the exact same tuple is already valid in *References*. Nothing to do.

After all reference tuples are inserted, we invalidate every tuple in *References* that is not in the inserted dump (it means that the reference has been removed from the record).

<caption>**Algorithm 4 INSERT_OR_UPDATE_REF**</caption>

Input: *tuples*
Input: *dd*
1: **for all** *t* ∈ *tuples* **do**
2: &nbsp;&nbsp;&nbsp;&nbsp;**if not** *IS_VALID*(*t*, *References*) **then**
3: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INSERT(*t*, *References*, *dd*, nil)
4: &nbsp;&nbsp;&nbsp;&nbsp;**else if not** *IS_EXACTLY_IN*(*t*, *References*) **then**
5: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INVALIDATE(*t*, *References*, *dd*)
6: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INSERT(*t*, *References*, *dd*, nil)
7: &nbsp;&nbsp;&nbsp;&nbsp;**end if**
8: &nbsp;&nbsp;&nbsp;&nbsp;**end for**
9: **for all** *t* ∈ *SELECT_VALID*(*References*) **do**
10: &nbsp;&nbsp;&nbsp;&nbsp;**if** *PRIMARY_KEY*(*t*) ∉ *PRIMARY_KEYS*(*tuples*) **then**
11: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INVALIDATE(*t*, *References*, *dd*)
12: &nbsp;&nbsp;&nbsp;&nbsp;**end if**
13: **end for**

The last challenge to overcome when inserting Crossref records is that some previously defined attributes are not in Crossref records and need to be calculated. For instance, `articleToArticle` is a boolean that marks the references that link two records of type `journal/proceeding article`. Put differently, this boolean is false for references concerning a source or a target that are not of these two types (e.g., `pre-print`, `book-chapter`). Since each relation contains millions of tuples, the execution plan (Figure 5) requires significant resources. We precalculate this attribute as it is slow to compute and we do it only once so that any further attribute use is faster.

The tuple *r* to consider for an update in *References* might be older than the last inserted dump, because either one of the citing or cited records have been updated more recently. Taking this additional constraint into account, we reduce the update task to 3 cases, provided that the default value of `articleToArticle` = 1:

1) *r* has just been inserted (validFrom = date of the inserted dump) and either the citing or the cited records are not articles. In this case we update the value to 0.

2) *r* was in the *References* before the insertion of the dump and `articleToArticle` = 1, but either the type of the citing or the cited articles recently changed to something other than an article. We invalidate the previous tuple and we insert a valid copy with `articleToArticle` = 0.

3) *r* was in the *References* before the insertion of the dump and `articleToArticle` = 0, but either the type of the citing or the cited articles recently changed and both are now articles. We invalidate the previous tuple and we insert a valid copy with `articleToArticle` = 1.

3) Anomaly Detection Metrics: In this section, we show-case how two metrics can be computed against the proposed

<figure><img src="image_6.png" /><figcaption>Fig. 5. Execution plan to obtain all references that are in a published articles and are directed published a articles.</figcaption></figure>

model. These metrics are citation-based, and require the use of the 3 introduced relations (*Articles*, *Authors*, and *References*). We designed these metrics to uncover potential citation-related misconducts, restricted to authors and journals. An application would be the discovery of made-up journals that would cite only one author.

Authors that benefit from *sneaked references* [21] show three main characteristics:

* They are in a hurry: they were found to add multiple times the same reference in the metadata.

* They are lazy: they add references at the end of the reference list.

* They are greedy: almost all of the citations they receive come from one manipulated journal. In addition, the manipulated journal over-cites the greedy 'fraudster' abnormally (e.g., 70% of the journal's outward citations point to that person).

Besançon et al. [21] worked on the first and second characteristics. We conceptualize in this paper two metrics to address the third characteristic. Let:

* D be the set of articles in *Articles*, both journals and conferences (attribute DOI).

* A be the set of authors in *Authors* (attribute author).

* And J be the set of venues in *Articles*, both journals and conferences (attribute venue).

We define the following operators:

* For $a \in A$ and $d \in D$, $a \rightleftharpoons d$ if and only if $a$ is an author of $d$.

* For $d \in D$ and $j \in J$, $d \rightleftharpoons j$ if and only if $d$ is published in venue $j$.

* For $(d_1, d_2) \in D^2$, $d_1 \to d_2$ if and only if $d_1$ cites $d_2$, i.e. $d_2$ is in $d_1$'s bibliography. This link is stored in *References*.

We build with these operators:

* $D_j$ the set of documents published in venue $j \in J$: $D_j = \{d \in D | d \rightleftharpoons j\}$.

* $R_d$ the set of references in the bibliography of $d \in D$: $R_d = \{(d, r) \in D^2 | d \to r\}$.
These elements allow us to define the two metrics. The Concentration $s_c$ is the proportion of inward citations benefiting an author coming from articles from a specific venue. For a venue $j$ and an author $a$, this metric is defined by:

$$s_c(j, a) = \frac{\sum_{d \in D_j} |\{(d, r) \in R_d | a \rightleftharpoons r\}|}{\sum_{d \in D} |\{(d, r) \in R_d | a \rightleftharpoons r\}|}$$

The Saturation $s_s$ is the proportion of outward citations in articles published in a venue benefiting a specific author. For a venue $j$ and an author $a$, this metric is defined by:

$$s_s(j, a) = \frac{\sum_{d \in D_j} |\{(d, r) \in R_d | a \rightleftharpoons r\}|}{\sum_{d \in D_j} |R_d|}$$

Both of these metrics are not normalized by the number of authors in cited articles: one citation of an article having five authors is equivalent to five whole citation links (one per author). Note that despite this, we find these metrics relevant because high values would be considered abnormal. For example, it should be extremely rare to find a venue that has 55% of its outward citations directed to a single author.

We aggregate both metrics in a harmonic average score, allowing ranking tuples with both metrics at the same time:

$$s_h(j, a) = \frac{2 \times s_s(j, a) \times s_c(j, a)}{s_s(j, a) + s_c(j, a)}$$

To highlight authors that could be suspect, we define the weighted arithmetic average of $s_h$ over authors, where the higher this score is, the more suspect an author would be:

$$\overline{s_h}(a) = \frac{\sum_{j \in J} \left( \sum_{d \in D_j} |\{(d, r) \in R_d | a \rightleftharpoons r\}| \times s_h(j, a) \right)}{\sum_{d \in D} |\{(d, r) \in R_d | a \rightleftharpoons r\}|}$$

**Example.** To illustrate the previous definitions:

$s_c(\text{'Daily Planet', 'Clark Kent'}) = 0.98$ means that 98% of the citations benefiting the author CLARK KENT come from the venue *Daily Planet*.

$s_s(\text{'Daily Planet', 'Clark Kent'}) = 0.55$ means that 55% of the citations in articles published in the venue *Daily Planet* benefit (i.e. cite) the author CLARK KENT.

In this case, $s_h(\text{'Daily Planet', 'Clark Kent'}) = 0.70$

To conclude this section, we add a temporal dimension to these metrics. We define the notation $[S]_{t_2}^{t_1}$ as the state of the expression $S$ taking into account only the tuples where validFrom $\ge$ $t_1$ and validTo $< t_2$. Similarly, $[S]_{t_2}^{t_1}$ is the state of $S$ only taking into account the tuples where validFrom $\ge$ $t_1$, and $[S]_{t_2}^{t_1}$ is the state of $S$ only taking into account the tuples where validTo $< t_2$.

**Example.**

* $[s_c(j, a)]_{202505}$ was the Concentration of author $a$ in venue $j$ at the beginning of May 2025.

* $[s_c(j, a)]_{202001}$ is the Concentration of author $a$ in venue $j$ when only taking into account works published after 2020 (included).

* $[s_c(j, a)]_{202505}^{202001}$ was the Concentration of author $a$ in venue $j$ at the beginning of May 2025, when only taking into account works published after 2020 (included).

We define the monthly and quarterly Concentration and Saturation, respectively $s_c^m, s_c^q, s_s^m, \text{ and } s_s^q$. As an example, monthly Concentration is defined as follows:

$$s_c^m(j, a, t) = \frac{\left[ \sum_{d \in D_j} |\{(d, r) \in R_d | a \rightleftharpoons r\}| \right]_{t+1}^t}{\sum_{d \in D} |\{(d, r) \in R_d | a \rightleftharpoons r\}|}$$

Both quarterly and monthly metrics are designed to capture abnormal citation spikes, but on different scales. The quarterly metrics can better detect abnormal citation patterns distributed on more than a single month.

Note: because $[S]_{t_2}^{t_1}$ is defined as a relational algebra selection, for all expressions $S_1$ and $S_2$:

* $[S_1 + S_2]_{t_2}^{t_1} = [S_1]_{t_2}^{t_1} + [S_2]_{t_2}^{t_1}$

* $[S_1 \times S_2]_{t_2}^{t_1} = [S_1]_{t_2}^{t_1} \times [S_2]_{t_2}^{t_1}$

However, the monthly Concentration (resp. Saturation) is not the same metric than the Concentration (resp. Saturation) computed on the tuples from a specific month, i.e. $s_c^m(j, a, t) \neq [s_c(j, a)]_{t+1}^t$ and $s_s^m(j, a, t) \neq [s_s(j, a)]_{t+1}^t$.

## B. Design: Implementation

We chose to implement our AllDumps-1DB model in an Oracle relational database. We developed a Python script, using the oracledb library,<fnref n="12" /> to populate it with records from Crossref dumps. This script is made to insert data into an Oracle database specifically, but it can easily be adapted to other relational databases.

This script is executed according to the following plan. For each dump:

1) If this dump is the first to be loaded,

* create one table per relation: Articles, Authors, and References,

* create all indexes presented in Table I to improve performances on columns expected to be read frequently.

2) Disable (temporarily) indexes for faster data importation.

3) Read data from the Crossref dump archive, and populate the tables with an implementation of our algorithms (see Algorithms 1 to 4).

4) Rebuild indexes.

5) For easier analyses, create views presenting rows valid after insertion of the current dump. For instance, view CR202501onisects all rows from Articles having validFrom $\le$ 202501 and validTo $> 202501$ or nil.

<footnote n="12">¹²https://pypi.org/project/oracledb/</footnote>
<table><caption>TABLE I
LIST OF ALL RELATIONAL TABLES AND THEIR INDEXES</caption><thead><tr><th>Table</th><th>Index Type</th><th>Columns</th></tr></thead><tbody><tr><td rowspan="7">Articles</td><td>Primary Key</td><td>DOI, VALIDFROM, VALIDTO<br>VALIDTO<br>VALIDFROM<br>TYPE<br>TITLE</td></tr><tr><td>B-TREE</td><td>VALIDFROM, VALIDTO<br>VENUE<br>CREATED<br>PUBLISHED<br>PUBLISHER</td></tr><tr><td>Primay Key</td><td>DOI, AUTHOR, VALIDFROM, VALIDTO</td></tr><tr><td>B-TREE</td><td>VALIDTO<br>VALIDFROM<br>VALIDFROM, VALIDTO<br>AUTHOR</td></tr><tr><td>Primary Key</td><td>DOI, REFERENCE, VALIDFROM, VALIDTO<br>REFERENCE<br>VALIDTO</td></tr><tr><td>B-TREE</td><td>VALIDFROM<br>VALIDFROM, VALIDTO<br>COUNT</td></tr><tr><td>BITMAP</td><td>assertedBY<br>ARTICLE_TO calLE</td></tr></tbody></table>

6) Fill in the auxiliary columns with our algorithms, like `REFERENCE. ARTICLE_TO calLE`, for which there are no explicit data in the Crossref dumps.

The aforementioned indexes are mostly B-TREE indexes. We applied BITMAP indexes on specific columns: `REFERENCE. ARTICLE_TO calLE`, with values in `{0, 1}`, and `REFERENCE. ASSE RTE DBY`, with values in `{0, 1, 2}`.

For our model to be as efficient as possible, we used several strategies, the main ones being:

* Batch inserting.

* SQL Data Modeling Language with parallel hint.

* Disabling of specific database logs.

* Minimizing the number of queries made to the database.

We also implemented an authors names disambiguator based on simple rules: the name and surname of each author are concatenated and cleaned to remove punctuation, titles, and institutions.

The aforementioned implementation allows easy SQL querying on the Oracle database. For instance, the SQL query to get the citation count of every author in Crossref records, as they were in May 2025, is:

```sql
SELECT author.author, count(*) as cnt
FROM CR202505_AUTHOR author
JOIN CR202505_REFERENCE ref
  ON author.doi = ref reference
WHERE ref.article_to_article = 1
GROUP BY author.author
ORDER BY cnt DESC;
```

As another example, counting the number of written preprint per author is trivial:

```sql
SELECT author.author author, count(*) cnt
FROM CR202505_AUTHOR author
JOIN CR202505 calLE ref
  ON author.doi = ref.doi
WHERE article.type = 'pre-print'
GROUP BY author.author
ORDER BY cnt DESC;
```

### III. RESULTS

For reproducibility purposes, we provide the Oracle database server specifications: 2xCPU Xeon 4215R, 256GB RAM, 10TB SSD. Our Python script is executed on a server with the following characteristics: 2xCPU Xeon 6128, 187GB RAM, 2TB SSD.

We inserted into our local Oracle database four Crossref dumps: April to July 2025. For our experimentations, we only inserted records created during or after 2020. These records represent half of all Crossref records.

#### A. Comparison with Other Models

To evaluate the performances of our *AllDumps-1DB* method, we compared it with two alternatives:

* Oracle's versioning system,<fnref n="13" /> tested with the April 2025 dump only.

* A naive system (codenamed *1Dump-1DB*), which consists of inserting each dump into a different database. The major downside of the *1Dump-1DB* method is that records present in several dumps are inserted multiple times.

As shown in Table II, our *AllDumps-1DB* method outperforms Oracle's versioning system in insertion times. We gave up on computing the *ARTICLE_TO calLE* column with the latter method: the estimated completion time was higher than one year. Given the poor performances, we did not try to insert another dump with it. The inserting phase of *AllDumps-1DB* is slightly slower than the *1Dump-1DB* one. This is true even for the first dump insertion, which only inserts data without any checks. This can be explained by the indexes and columns we added to handle the validity time ranges (*validFrom* and *validTo*).

While insertion of data is slower with *AllDumps-1DB*, the number of rows will not increase much after the initial insertion. Indeed, when inserting a subsequent dump, rows without any modification will not be inserted.

The total used tablespace for our *AllDumps-1DB* method is 359 GB for April, May, June, and July 2025 (taking into account all tables and their indexes). Oracle's versioning system generated 431 GB of data for April only. These differences are likely imputable to the abstraction difference between the two methods. Oracle's system was conceived to offer a diverse set of features and to handle continuous overlapping periods. Ours was conceived for monthly discrete points.

<footnote n="13">¹³https://docs.oracle.com/en/database/oracle/oracle-database/18/adwsm/valid-time-support.html</footnote>
<table><caption>TABLE II
DUMPS INSERTING TIME AND WEIGHT COMPARISON</caption><thead><tr><th>Method</th><th>Dump</th><th>Inserting Time (hrs)</th><th>ARTICLE_TO Put Article Computing Time (hrs)</th><th>Inserted Rows (10<sup>6</sup>)</th></tr></thead><tbody><tr><td rowspan="4">AllDumps-1DB</td><td>Apr 2025*</td><td>17</td><td>6.0</td><td>976</td></tr><tr><td>May 2025</td><td>18</td><td>0.3</td><td>2</td></tr><tr><td>Jun 2025</td><td>18</td><td>6.0</td><td>2</td></tr><tr><td>Jul 2025</td><td>18</td><td>0.5</td><td>2</td></tr><tr><td rowspan="2">Oracle versioning</td><td>Apr 2025*</td><td>250</td><td>&gt; 1 year (est.)</td><td>976</td></tr><tr><td>May 2025</td><td>-</td><td>-</td><td>2 (est.)</td></tr><tr><td rowspan="2">IDump-1DB</td><td>Jan 2025*</td><td>10</td><td>6.0</td><td>927 (est.)</td></tr><tr><td>Feb 2025</td><td>10 (est.)</td><td>6.0</td><td>972 (est.)</td></tr></tbody></table>

Finally, computing the number of citations is twice as long using *AllDumps-1DB*. This is due to the additional operations required to handle validity periods (fields validFrom and validTo).

## B. Result Analysis

We computed the Saturation $s_s$ and Concentration $s_c$ metrics on both the January<fnref n="14" /> and April 2025 Crossref dumps. Table III displays the author-venue pairs linked by 40 or more citations. Those results revealed a previously known case of sneaked references, as well as new cases of a suspect author and a suspect journal, unrelated to sneaked references.

1) **Previously Reported Case of Sneaked References:** The journal (IJISRT) alongside the authors described in [21] appears at the top of the January Concentration (with some authors reaching $s_c = 0.999$).

2) **Case of a Suspect Author:** We found a suspect author (codenamed AR) at the top of our metrics rankings. Their professional profile on Google Scholar indicates a *h*-index of 24, and we counted over 14 000 references to their work. They reached 50% in Saturation and 98% in Concentration on Qeios, a new pre-print platform. This platform allows the conversion of pre-prints into journal articles once five positive peer reviews have been shared by Qeios' community. As a consequence, it sends pre-prints, peer-reviews and journal-article records to Crossref. We found out that AR Crossref entries were almost exclusively made of Qeios peer-reviews. However these peer reviews were classified as journal-articles in Crossref. Scientific platforms relying on Crossref data are therefore deceived, and count these reviews as scientific articles. We suspect AR found this vulnerability in the platform and exploited it to increase its visibility. AR's citation count also rose, as these entries often cited one another. We reported this case to Crossref in February 2025. In March, we noticed the vulnerability was partially corrected and not reproducible. However, Qeios did not update the majority of AR's records, which are still identified as journal articles. This means that Crossref and the downstream products Dimensions and Google Scholar are still polluted

by these data. Our contributed model could help track the evolution of these undue citations.

3) **Case of a Suspect Journal:** Our metrics identified suspect authors, but also highlighted anomalous publishers. In January 2025, the author GA was benefiting from 50% (> 250) of the references in bibliographies of articles published in *Journal of Information, Communication and Intelligence Systems*. After investigation, we noted that all members of the editorial board are renowned and sometimes emeritus scientists, but they all study different fields unrelated to the journal's theme. A significant part of the published articles we explored seem to contain added references, all benefiting to GA. There references are never cited in the article's content, and are even sometimes formatted in a different manner than the rest of the bibliography (different font and size).

4) **Metrics Trends Over a Month:** In addition to the appearance of new articles, our model allows the tracking of specific modifications in bibliographies. We captured the trend of $\bar{s}_h$ metrics over January and April dumps in Table IV. Notice how:

* AR's Saturation increases from January to April, despite a partial correction of Qeios' records in March.

* Two new authors (MF and SS) appear the metric rankings.

## IV. DISCUSSION

Our results show that our model and the implementation of our algorithms enables the recording and the mining of large longitudinal Crossref data, with affordable tools and moderate processing time. For this article, we experimented by loading 4 dumps and observed limited growth both in terms of rows and query execution time, suggesting that our approach is scalable.

Our method inserts new tuples only when changes occur, and Crossref evolves slowly (recent dumps are only twice the size of those from 2018). However, our model and metrics can still be improved in various ways.

The first limitation of our current model is that the insertion of dumps must be done in chronological order. It is currently possible to skip the insertion of a dump (for instance, to insert May and July in a row), but it is impossible to import the

<footnote>*First dump to be inserted</footnote>

<footnote n="14">¹⁴For January 2025, Concentration and Saturation were computed using data inserted with the *IDump-1DB* method.</footnote>
<table><caption>TABLE III
TOP 10 AUTHOR-VENUE Tuples OF THE CONCENTRATION $s_c$ AND SATURATION $s_s$ METRICS COMPUTED ON THE APRIL 2025 DUMP</caption><thead><tr><th>Author</th><th>Venue</th><th>Concentration</th><th>Saturation</th><th>Harmonic average</th></tr></thead><tbody><tr><td>ALV</td><td>Spravochnik. Inzhenernyi zhurnal</td><td>0.80</td><td>0.37</td><td>0.51</td></tr><tr><td><strong>AR</strong></td><td><strong>Qeios</strong></td><td>1.00</td><td>0.29</td><td>0.45</td></tr><tr><td>ANZR</td><td>Journal of Optical Communications</td><td>0.80</td><td>0.22</td><td>0.35</td></tr><tr><td>MK</td><td>2023 IEEE International Conference on Cybernetics and Innovations (ICCI)</td><td>0.32</td><td>0.30</td><td>0.31</td></tr><tr><td>AHA</td><td>2024 Asian Conference on Communication and Networks (ASIANComNet)</td><td>0.39</td><td>0.24</td><td>0.30</td></tr><tr><td>MM</td><td>Journal of Community Pharmacy Practice</td><td>0.28</td><td>0.24</td><td>0.26</td></tr><tr><td>YABEE</td><td>2023 International Conference on Computer Science and Emerging Technologies (CSET)</td><td>0.48</td><td>0.17</td><td>0.25</td></tr><tr><td>PG</td><td>Annals of Psychiatry and Treatment</td><td>0.36</td><td>0.18</td><td>0.24</td></tr><tr><td>CC</td><td>Pindus Journal of Culture Literature and ELT</td><td>0.17</td><td>0.43</td><td>0.24</td></tr><tr><td>MH</td><td>2021 International Conference on Innovative Computing (ICIC)</td><td>0.32</td><td>0.17</td><td>0.23</td></tr></tbody></table>

<table><caption>TABLE IV
TRENDS OF TOP 10 AUTHORS BY $\bar{s}_h$ SCORE (JANUARY VS APRIL)</caption><thead><tr><th rowspan="2">Author</th><th colspan="2">Author Citation Count</th><th colspan="2">$\bar{s}_h$ Score</th><th rowspan="2">Trend</th></tr><tr><th>January</th><th>April</th><th>January</th><th>April</th></tr></thead><tbody><tr><td>RF</td><td>291</td><td>319</td><td>0.986</td><td>0.984</td><td>↓</td></tr><tr><td>MF</td><td>-</td><td>96</td><td>-</td><td>0.701</td><td>*</td></tr><tr><td>MG</td><td>298</td><td>300</td><td>0.684</td><td>0.683</td><td>↓</td></tr><tr><td>S1</td><td>81</td><td>82</td><td>0.590</td><td>0.587</td><td>↓</td></tr><tr><td>SG</td><td>215</td><td>215</td><td>0.516</td><td>0.516</td><td>=</td></tr><tr><td><strong>AR</strong></td><td>8894</td><td>14477</td><td>0.446</td><td>0.498</td><td>↑</td></tr><tr><td>SS</td><td>-</td><td>324</td><td>-</td><td>0.460</td><td>*</td></tr><tr><td>DG</td><td>186</td><td>191</td><td>0.445</td><td>0.442</td><td>↓</td></tr><tr><td>AS</td><td>146</td><td>147</td><td>0.440</td><td>0.439</td><td>↓</td></tr><tr><td>AV</td><td>865</td><td>895</td><td>0.418</td><td>0.415</td><td>↓</td></tr><tr><td>GR</td><td>146</td><td>155</td><td>0.411</td><td>0.403</td><td>↑</td></tr><tr><td>LG</td><td>73</td><td>81</td><td>0.369</td><td>0.386</td><td>↑</td></tr></tbody></table>

Trend legend:

= The author's score remained constant between the dumps.

↑ The author's score increased from one dump to the next.

↓ The author's score decreased from one dump to the next.

* The author is new in the ranking.

missing dump afterwards (June in our example). Nevertheless, we plan to implement the reverse chronological order.

Another limitation is that our model might miss subtle changes. Two modifications canceling each other out within less than a month would be invisible for us (for example, the addition and subsequent removal of an author).

Data cleaning is another challenge. Crossref records are heterogeneous and semi-structured (i.e. the JSON format might differ from one record to the other). We often found examples of a wrong use of Crossref structure to store data, such as using the first and last name attributes to record two co-authors. Even when the names are properly stored, the disambiguation of author names is also not a trivial problem [22]. Most methods for doing so are computationally expensive, especially on large datasets. Our disambiguation method can be improved—it may occasionally merge distinct authors and collapse them in our rankings—but it offers a reasonable trade-off between accuracy and computation time. References can also require some cleaning. Crossref usually tries to extract a DOI when one is not provided by the publisher, but it is not always done. We currently have no method to infer them at scale from the provided *unstructured* field. This field is hard to exploit

since it contains various attributes (title, DOI, author name, venue) in no particular order.

Furthermore, while our model enables a wide range of analyses, we have no way to automatically verify that the anomalies we detect are true cases of misconduct. Each detected anomaly requires a manual follow-up analysis to ensure its context and pertinence. We would be happy to collaborate with specialists to review our analyses, such as integrity officers from Crossref, COPE<fnref n="15" />, or to the publishers themselves. Our metrics also have conceptual limitations: a cartel of authors monopolizing a journal would reduce saturation, and an author accumulating citations from several journals would reduce concentration.

Finally, we chose to develop and implement a method on a single-node database. Our intention was to make the method widely accessible, particularly in a context where much of the work on scientific misconduct is carried out by independent researchers. The performance of our system might be improved by deploying it on a distributed architecture, or by relying on database management systems like Neo4j or MongoDB.

## V. CONCLUSION

We introduced an affordable method to store and mine Crossref data longitudinally. This method is used to perform analyses using statistical metrics that we have designed to uncover anomalies in these data. Those highlight interesting interactions and trends between some authors and journals, which would not have been visible without mining the history of Crossref data.

This work was initiated to find new cases of *sneaked references* [8]. A previous approach, consisting on comparing PDFs references with Crossref recorded references on a set of articles [21], revealed that added references were benefiting to a small amount of authors. We plan to use our model to check whether the reveal of this malpractice motivated updates from some publishers to remove *sneaked references*.

Our metrics are computed frequently and could help to discover new misconducts or suspect cases. Over time, they could allow us to develop monthly dashboards to monitor scientific literature and flag suspicious citation patterns. As

<footnote n="15">¹⁵https://publicationethics.org</footnote>
<table><caption>TABLE V
TOP 10 AUTHOR-VENUE TUPLES OF THE (APPROXIMATED) MONTHLY SATURATION $s_s^m$ METRIC COMPUTED ON THE APRIL 2025 DUMP.
THIS APPROXIMATION WAS COMPUTED BY FILTERING CITATIONS ON THEIR CROSSREF RECORD CREATION DATE.</caption><thead><tr><th>Month</th><th>Author</th><th>Venue</th><th>Cit. count</th><th>Journal cit. count</th><th>Saturation</th></tr></thead><tbody><tr><td>2024/12</td><td>SAS</td><td>Materials of the All-Russian Scientific and Practical Conference</td><td>155</td><td>236</td><td>0.66</td></tr><tr><td>2023/06</td><td>CG</td><td>Proc. of the 6th Annual ACM Lifelog Search Challenge</td><td>77</td><td>165</td><td>0.47</td></tr><tr><td>2024/07</td><td>CC</td><td>Pindus Journal of Culture Literature and ELT</td><td>93</td><td>218</td><td>0.43</td></tr><tr><td>2024/07</td><td>IPS</td><td>Tsabit Journal of Computer Science</td><td>66</td><td>166</td><td>0.40</td></tr><tr><td>2021/04</td><td>S</td><td>U-NET Jurnal Teknik Informatika</td><td>47</td><td>136</td><td>0.35</td></tr><tr><td>2020/05</td><td>KBITOTRAS</td><td>Geobotanical Mapping</td><td>87</td><td>255</td><td>0.34</td></tr><tr><td>2022/06</td><td>CG</td><td>Proc. of the 5th Annual on Lifelog Search Challenge</td><td>46</td><td>137</td><td>0.34</td></tr><tr><td>2024/06</td><td>OA</td><td>Bersama: Jurnal Pengabdian Masyarakat</td><td>68</td><td>203</td><td>0.33</td></tr><tr><td>2024/06</td><td>CG</td><td>Proc. of the 7th Annual ACM Workshop on the Lifelog Search Challenge</td><td>52</td><td>158</td><td>0.31</td></tr><tr><td>2025/03</td><td>IPS</td><td>Tsabit Journal of Computer Science</td><td>52</td><td>166</td><td>0.31</td></tr></tbody></table>

future work, we plan to compute the monthly Saturation $s_s^m$ using all Crossref dumps. In the meantime, we provide an approximation of the monthly Saturation $s_s^m$ in Table V to illustrate its use. This approximation was computed on the April 2025 dump, by filtering the citations using the Crossref record creation date (created field). Note that these results might differ slightly from the true monthly Saturation, due to potential modifications of records.

## CODE AVAILABILITY

The Python implementation of AllDumps-1DB is available on Zenodo: 10.5281/zenodo.17662564.

## ACKNOWLEDGMENT

The authors acknowledge that artificial intelligence tools were used solely for translation assistance and LATEX formatting. No part of the research design, analysis, or interpretation relied on AI systems.

## REFERENCES

[1] C. J. Crous, "The darker side of quantitative academic performance metrics," *South African Journal of Science*, vol. 115, no. 7/8, 2019. doi: 10.17159/sajs.2019/5785.

[2] C. Labbé, "Ike Antkare one of the great stars in the scientific firmament," *International Society for Scientometrics and Informetrics Newsletter*, vol. 6, no. 2, pp. 48-52, 2012. [Online]. Available: https://hal.science/hal-00713564v1

[3] I. Antkare, "Ike Antkare, His Publications, and Those of His Disciples," in *Gaming the Metrics*, M. Biagioli and A. Lippman, Eds. Cambridge, MA: The MIT Press, 2020, pp. 177-200. ISBN 978-0-262-35656-5

[4] E. Delgado López-Cózar, N. Robinson-García, and D. Torres-Salinas, "The Google Scholar experiment: How to index false papers and manipulate bibliometric indicators," *Journal of the Association for Information Science and Technology*, vol. 65, no. 3, pp. 446-454, 2014. doi: 10.1002/asi.23056.

[5] H. Ibrahim, F. Liu, Y. Zaki, and T. Rahwan, "Citation manipulation through citation mills and pre-print servers," *Scientific Reports*, vol. 15, no. 1, p. 5480, 2025. doi: 10.1038/s41598-025-88709-7.

[6] M. Biagioli and A. Lippman, Eds., *Gaming the Metrics: Misconduct and Manipulation in Academic Research*. Cambridge, MA: The MIT Press, 2020. ISBN 978-0-262-35656-5

[7] E. Sercan, "Rețeaua citărilor fictive. Un universitar iesean și a crescut reputația academică plantându-și fraudulos lucrările în bibliografiile a circa 200 de articole stiintifice [The network of fictitious citations. An academic from Iași increased his academic reputation by fraudulently planting his works in the bibliographies of about 200 scientific articles]," *Press One*, 2025. [Online]. Available: https://pressone.ro/reteaua-citarilor-fictive-un-universitar-iesean-si-a-crescut-reputația-academica-plantandu-si-fraudulos-lucrarile-in-bibliografiile-a-circa-200-de-articole-stiintifice

[8] L. Besançon, G. Cabanac, C. Labbé, and A. Magazinov, "Sneaked references: Fabricated reference metadata distort citation counts," *Journal of the Association for Information Science and Technology*, vol. 75, no. 12, pp. 1368-1379, 2024. doi: 10.1002/asi.24896.

[9] R. Van Noorden, "Highly cited researcher banned from journal board for citation abuse," *Nature*, vol. 578, no. 7794, pp. 200-201, 2020. doi: 10.1038/d41586-020-00335-7.

[10] S. Kojaku, G. Livan, and N. Masuda, "Detecting anomalous citation groups in journal networks," *Scientific Reports*, vol. 11, no. 1, p. 14524, 2021. doi: 10.1038/s41598-021-93572-3.

[11] I. Fister and M. Perc, "Toward the discovery of citation cartels in citation networks," *Frontiers in Physics*, vol. 4, p. 49, 2016. doi: 10.3389/fphy.2016.00049.

[12] K. Hyland, "Self-citation and self-reference: Credibility and promotion in academic publication," *Journal of the American Society for Information Science and Technology*, vol. 54, no. 3, pp. 251-259, 2003. doi: 10.1002/asi.10204.

[13] M. Szomszor, D. A. Pendlebury, and J. Adams, "How much is too much? The difference between research influence and self-citation excess," *Scientometrics*, vol. 123, no. 2, pp. 1119-1147, 2020. doi: 10.1007/s11192-020-03417-5.

[14] A. W. Wilhite and E. A. Fong, "Coercive citation in academic publishing," *Science*, vol. 335, no. 6068, pp. 542-543, 2012. doi: 10.1126/science.1212540.

[15] B. D. Thombs, A. W. Levis, I. Razykov, A. Syamchandra, A. F. Leentjens, J. L. Levenson, and M. A. Lumley, "Potentially coercive self-citation by peer reviewers: A cross-sectional study," *Journal of Psychosomatic Research*, vol. 78, no. 1, pp. 1-6, 2015. doi: 10.1016/j.jpsychores.2014.09.015.

[16] J. Priem, H. Piwowar, and R. Orr, "OpenAlex: A fully-open index of scholarly works, authors, venues, institutions, and concepts," 2022, accessed: 2025-11-21. doi: 10.48550/arXiv.2205.01833.

[17] C. Herzog, D. Hook, and S. Konkiel, "Dimensions: Bringing down barriers between scientometricians and data," *Quantitative Science Studies*, vol. 1, no. 1, pp. 387-395, 2020. doi: 10.1162/qss_a_00020.

[18] R. Kimball and M. Ross, *The Data Warehouse Toolkit – The Definitive Guide To Dimensional Modeling.*, 3rd ed. John Wiley & Sons, 2013.

[19] S. Faisal and M. Sarwar, "Handling slowly changing dimensions in data warehouses," *Journal of Systems and Software*, vol. 94, pp. 151-160, 2014. doi: 10.1016/j.jss.2014.03.072.

[20] G. Wiederhold, S. Jajodia, and W. Litwin, "Dealing with granularity of time in temporal databases," in *CAiSE'91: Proceedings of the 3rd International Conference on Advanced Information Systems Engineering*, ser. LNCS, vol. 498. Berlin, Heidelberg: Springer, 1991. doi: 10.1007/3-540-54059-8_83. pp. 124-140.

[21] L. Besançon, G. Cabanac, C. Labbé, A. Magazinov, J. di Scala, D. Tkaczyk, and K. Weber-Boer, "Detection of metadata manipulations: Finding sneaked references in the scholarly literature," 2025, accessed: 2025-11-21. doi: 10.48550/arXiv.2501.03771.

[22] J. Kim, "Evaluating author name disambiguation for digital libraries: a case of DBLP," *Scientometrics*, vol. 116, no. 3, pp. 1867-1886, 2018. doi: 10.1007/s11192-018-2824-5.