Reading path: Underwater images and evidence →
Read what is offered
A data availability statement describes whether and how readers can access materials used in a study. Depending on the paper, those materials might include measurements, processed tables, code, images, or supplementary files. Read the statement closely: “available in a repository” is different from “available from the authors on request,” and neither phrase tells you everything about completeness or usability.
Note precisely which materials are named. A paper may share a table of analyzed values but not raw instrument output. It may provide code without the input files needed to run it. If you are interested in a result based on underwater images, check whether the images, annotations, and description of selection criteria are all available, or only a summarized count.
Look for location and access
When a repository is named, follow the link and check that it resolves to the intended project. Look for a stable identifier, version information, file descriptions, and any documentation that explains columns or units. A spreadsheet called “final data” can be difficult to interpret if it lacks a record of sampling dates, stations, or what a missing value means.
Access may be limited for legitimate reasons, such as sensitive locations or permissions attached to collected material. The statement should help you understand the restriction and how access is handled. Record whether files are openly downloadable, require an application, or are described as available only by request. Do not assume that a posted link means every reader can obtain every item.
Assess what can be checked
Availability helps independent readers inspect parts of the evidence, but it is not the same as successful replication. To assess a reported count, for example, you may need the underlying observations, a clear definition of what was counted, and enough method detail to reproduce the selection. Shared data without context can still be ambiguous; a methods section may explain the categories and exclusions.
Code can make an analysis easier to examine if it is documented and compatible with the supplied data. Check whether the paper identifies software versions or explains how the code connects to a figure or result. A repository might contain a script that produces one chart, while important processing steps happened elsewhere. Treat each link as evidence about a particular part of the workflow, not a guarantee of completeness.
Keep a transparent note
In your reading record, summarize what is accessible, where it is stored, and what remains unavailable or unclear. For example: “Processed station table is downloadable; instrument files are not listed; code is provided for the main figure.” This gives a future reader a practical account of the verification path without implying that you independently reran the analysis.
A data statement is a useful clue about transparency and access. Compare its promises with the materials you can actually locate, and check whether those materials answer your question. If important files are restricted, describe the limitation plainly. A careful reader can then distinguish a result that is open to direct inspection from one whose supporting materials are only partly accessible.
Have a correction or a source to suggest? Send a note →