Label the source, observation period and update date separately

Put a compact provenance block immediately above a public data table. Its labels should answer three different questions:

1. Where did the values come from?
2. What period do the values describe?
3. When did this published copy last change?

Do not compress those answers into an ambiguous line such as “Updated September 13.” A recently updated page can still contain observations from an earlier month or year.

Use this metadata block

For a table assembled from one source, publish a block like this:

Source: Example Statistics Agency — Monthly Employment Estimates Source release: September 12, 2026 Data coverage: August 1–31, 2026 This table updated: September 13, 2026, 14:30 UTC Page first published: September 13, 2026 Version: 2026-09-13.1 Processing note: Selected regional rows; standardized region names; no values recalculated.

This is a template, not a real dataset. Replace every value with information you can verify, and link the source name to the exact dataset or release page.

The labels are deliberately separate. DataCite distinguishes Collected, the period when content was collected, from Coverage, the period the content applies to (DataCite date types).

Define each date before publishing

Source release is the date assigned to the source edition by its original publisher. Copy it only when the source states it. Do not substitute your download time.

Data coverage is the observation or reference period represented by the values. It may be one date, a month, a year or a range. Schema.org similarly defines temporalCoverage as the period the content describes (Schema.org temporalCoverage). If different rows cover different periods, add explicit period_start and period_end columns instead of claiming one range for the whole table.

This table updated is when the public dataset’s values, rows, columns or documented transformations last changed. A routine page view, automated availability check or spelling correction should not make old observations look newly updated. If a correction changes interpretation, advance the date and explain the correction.

Page first published is when this public data page first became available. Schema.org defines datePublished as the date of first publication and dateModified as the most recent modification (Schema.org Dataset). Keep those properties attached to the dataset page or dataset entity they describe, not silently borrowed from the upstream source.

Version identifies the exact edition readers are viewing. A date-based value is easy to read; add a sequence suffix when you publish more than one edition in a day. Keep older versions or a change log when reproducibility matters.

Link to the exact source, not just its homepage

Use the most specific stable URL available: a dataset landing page, release page, API documentation page or archived source file. Name both the organization and dataset. If you combined sources, list each source and state which rows or fields it supplied.

Add a short processing note for filtering, joins, renamed categories, unit conversion, suppression or calculations. The W3C CSV on the Web primer treats description, authorship and licensing as metadata that can give users context about a CSV file (W3C CSV on the Web primer). That context should remain visible when a spreadsheet becomes an interactive public page rather than living only in a private workbook.

Keep provenance outside the data rows

Do not repeat the page update date in every row unless each row genuinely has its own update timestamp. Repetition bloats downloads and makes a page-level fact look like an observed variable.

Instead:

• place the provenance block before the table;
• give the table a caption that identifies its subject and coverage;
• reserve columns for row-level dates such as observation_date, period_start, period_end or source_updated_at;
• explain units, missing values and transformations in nearby notes.

A caption identifies a table’s overall topic (W3C Tables Tutorial). Use structural table markup to define the relationship between header and data cells so assistive technologies can provide context to users (W3C Tables Tutorial). For more help naming the dataset and explaining its structure, see Accessible Data Table Captions and Summaries.

Run a freshness check before every update

Before replacing the published file:

1. Open the linked source and verify its title, edition and release date.
2. Compare the new file with the current published version.
3. Confirm whether the observation period advanced or historical rows were merely revised.
4. Update the table date only if the public dataset changed.
5. Record material changes: added period, revised values, corrected labels or changed method.
6. Test the source link, table caption, filters and date columns on the finished public page.

The result lets a reader distinguish a table published today from data observed last month—and trace the displayed values back to the edition you actually used.