Give Your Public Dataset the Reference Materials Readers Need

Before publishing a spreadsheet, gather the reference materials a reader needs to answer three questions: What do these values mean? Where did they come from? What changed before publication?

For a public dataset, reference materials are the supporting documents and lookup tables that explain the data—not another copy of the spreadsheet. A compact pack might contain a README, column definitions, a source register and a short processing log. The result should let someone interpret a row and trace it back to its source without contacting you.

Choose materials by the question they answer

Start with this structure. These filenames are suggested conventions, not a platform requirement. For a small dataset, combine the source details, methods and release notes in the README; separate them when they become hard to navigate.

Material	Reader question	What to include
README.txt	What am I looking at?	Dataset purpose, what one row represents, coverage, release version, file list and reuse terms
data_dictionary.csv	What does this column mean?	Exact header, definition, type, unit, allowed values and missing-value rules
sources.csv	Where did this figure come from?	Source ID, publisher, title, URL, edition or release date, retrieval date and relevant table or section
methods.txt	How was the published table produced?	Filters, joins, conversions, calculations, exclusions and rounding
CHANGELOG.txt	What changed between releases?	Version, release date, changed records or fields and reason
codes.csv, if needed	What does this code stand for?	Code, label, definition and applicable edition or dates

A README is the entry point. The University of Auckland’s README guidance recommends documenting methods, file relationships, variable names, units, reuse terms and related materials alongside shared data.

For the column-level component, use the workflow in Build a Reference Sheet for a Public Dataset.

Record the source you actually used

Prefer the original publisher’s data file and documentation over a secondary summary. Check that the source matches your table’s subject, geography, time period and measure. A current webpage may describe a different edition from the file you downloaded.

In the source register, distinguish:

• Observation period: when the measurement applies.
• Source release date: when the publisher issued that edition.
• Retrieval date: when you obtained it.
• Your release version: which published table uses it.

Keep a local copy of the source file and its relevant documentation where permitted. Link readers to the original source; do not redistribute supporting documents unless their terms allow it. Do not treat public availability as permission to republish. W3C’s Data on the Web Best Practices calls for license information, provenance and compliance with licensing terms.

If the table combines sources, add a source_id field to the data where useful. If different columns come from different publishers, document provenance by column rather than implying that one row-level source covers everything.

Explain transformations, not just origins

A source link cannot explain what you did after downloading the file. W3C’s provenance guidance recommends providing information about both the origins of data and changes you have made.

For a fictional branch-library visits dataset, a useful methods note might say:

Each row represents one branch in one calendar month. Annual totals were excluded. Branch codes were matched using the code list supplied with the source release. Visits were retained as whole-number counts. Blank counts mean the source supplied no value; they were not converted to zero.

Replace those statements with your actual decisions. Record join keys, unmatched records and formulas for derived fields. If you changed units or rounded values, state the conversion and whether rounding happened before or after calculations.

Make limitations specific: “Two branches did not report for March” is more useful than “Data may be incomplete.” W3C recommends documenting known quality issues and fitness for use.

Publish the table and references as a matched release

Give the data and supporting files the same release identifier. Update the dictionary when a column changes, the source register when an edition changes, and the methods note when a calculation changes. Keep a brief change log rather than silently replacing corrected values; W3C recommends both a version indicator and version history.

As of October 9, 2026, TablePage’s homepage describes uploading CSV, TSV, XLSX or XLS files to generate a public, filterable dataset page. Prepare a separate, publication-safe data file for that upload. Keep long methods and source notes outside the observation rows, and place links to the table and reference pack together on your accompanying webpage or article.

Before sharing, check the published result:

• Do column names exactly match the dictionary?
• Can a reader trace a value to the right source edition?
• Are units, missing values and exclusions explained?
• Do the table and reference files show the same version?
• Are all links accessible without your account?
• Have you excluded sensitive data, private notes and restricted supporting files?

The final test is practical: choose one row and follow its definitions, source and processing notes. If that path breaks, fix the reference pack before publishing.