Tracking how a literature changes between retrievals

The baseline

The first retrieval ran at the end of 2023 and returned everything published up to then.

baseline <- example_records[example_records$year <= 2023, ]
nrow(baseline)

[1] 124

A later retrieval

A year on, the search is repeated. It now picks up the 2024 papers, and one record that was present the first time has since been re-indexed and no longer matches.

later <- example_records[-1, ]
nrow(later)

[1] 137

What changed

scopus_diff_dois() reports which DOIs were added, removed or unchanged between the two retrievals, and prints the counts in each category.

changes <- scopus_diff_dois(old = baseline, new = later)
print(changes)

<scopus_doi_diff> 14 added, 1 removed, 112 unchanged
# A tibble: 127 × 2
   doi                            status
   <chr>                          <fct> 
 1 10.1002/adfm.202315137         added 
 2 10.1002/asia.202400548         added 
 3 10.1002/slct.202302535         added 
 4 10.1016/j.cej.2024.148822      added 
 5 10.1016/j.diamond.2024.110842  added 
 6 10.1016/j.isci.2024.111696     added 
 7 10.1016/j.jallcom.2024.175000  added 
 8 10.1016/j.jallcom.2024.177248  added 
 9 10.1016/j.jpowsour.2024.234127 added 
10 10.1016/j.jpowsour.2024.236149 added 
# ℹ 117 more rows

The newly indexed papers come back as added, the records present both times as unchanged, and anything dropped from the later pull as removed. The counts work out at fourteen added, one removed and 112 unchanged. Fourteen are added because that is how many of the 2024 papers carry a DOI, and the re-indexed record takes the unchanged count from 113 down to 112. Records without a DOI cannot be tracked this way at all, which is one reason to prefer the ‘Scopus’ identifier when there is one.

To act on one category, filter the table, which is an ordinary tibble.

head(changes[changes$status == "added", ])

Merging without duplicates

To keep a cumulative set across retrievals, combine them. scopus_combine() renumbers the records and, with dedupe = TRUE, keeps each one once by ‘Scopus’ identifier or DOI, so the records the two pulls share are not doubled.

combined <- scopus_combine(baseline, later, dedupe = TRUE)
nrow(combined)

[1] 149

That is 149 rows for 138 distinct articles, and the gap is instructive. These records carry no ‘Scopus’ identifier, never having come from ‘Scopus’, so de-duplication falls back to the DOI. The eleven that arrived without one have no key to match on, and so survive in both copies. A live harvest carries an identifier on every record, so the same call on two real pulls returns each article once.

The base c() method concatenates record sets directly, renumbering but without de-duplicating, so it is the building block that scopus_combine() adds the duplicate handling to.

stacked <- c(baseline, later)
nrow(stacked)

[1] 261

Keeping a record of each pull

Saving each retrieval lets you compare against it next time. The .rds form round-trips exactly.

path <- file.path(tempdir(), "baseline.rds")
write_scopus_records(baseline, path)
identical(read_scopus_records(path), baseline)

[1] TRUE

A live retrieval also carries the date it was taken, as the retrieved_at attribute, together with the scopusflow version that took it. That matters for this workflow in particular, because citations is a snapshot value that keeps moving, so a difference between two pulls only means something once you know how far apart they were. Both survive the .rds form and neither survives .csv, which is a table of columns. The bundled corpus used here carries neither, which is why it round-trips identically above.

In a live setting the later retrieval would come from the API, where here it is a slice of the bundled corpus, and everything else would be as above. Both pulls could then say when they were taken.

later <- scopus_fetch("graphene supercapacitor", field = "TITLE-ABS-KEY")
attr(later, "retrieved_at")
scopus_diff_dois(old = read_scopus_records(path), new = later)