The ref_summary module does not run a check of its own. Instead it collects the results of the other reference-section modules — accuracy, PubPeer, replication, and retraction — into a single table with one row per reference, so you can see everything known about each cited work in one place.
ref_summary only collects the results of modules that ran before it; it does not run them itself. Because ref_accuracy is, for now, not among report()’s default modules, the accuracy columns stay empty in a default report. Add "ref_accuracy" to modules, before "ref_summary", to fill them.
Because it summarises the output of those modules, ref_summary must run after them, in the same report. On its own it has nothing to summarise.
Of the modules it summarises, only ref_pubpeer makes live network calls (to PubPeer), so the example below needs an internet connection. ref_retraction and ref_replication run offline on databases that ship with Metacheck, and ref_accuracy reads the CrossRef records already stored in the paper’s bib_match table.
The summary needs the other reference modules to have run first. The natural way to arrange that is to run them together with report_module_run(), which keeps each module’s output and passes the chain along (see Creating a Metacheck Report). List ref_summary last:
paper <- demopaper()
module_output <- report_module_run(
paper,
modules = c("ref_accuracy", "ref_pubpeer",
"ref_replication", "ref_retraction",
"ref_summary")
)
mo <- module_output[["ref_summary"]]
mo$traffic_light#> [1] "info"mo$summary_text#> [1] "Summary information provided for 5 references"The combined table has one row per reference and one column per upstream check:
| bib_id | accuracy_mismatch | pubpeer | replication_type | retractionwatch |
|---|---|---|---|---|
| 0 | no match | NA | NA | NA |
| 1 | NA | NA | replication | NA |
| 2 | NA | Link | NA | Retraction |
| 3 | author | NA | NA | NA |
| 4 | no match | NA | NA | NA |
A reference is interesting when any of these columns is filled in: a reported accuracy mismatch, a PubPeer comment, a replication (or reproduction), or a Retraction Watch entry. Follow up those references using the dedicated chapter for whichever column flagged it.
ref_summary inherits everything from the modules it summarises, so the same cautions apply: a filled-in cell is a prompt to look, not a verdict. Its value is convenience — instead of reading four separate tables, you scan one. The summary itself is informational (info); the underlying modules carry the traffic lights.
ref_summary takes only the paper argument, but it only produces useful output when the other ref_* modules have run before it in the same report.