Last updated/refreshed - UCD input required

[seanprivett]

This requires content input to remove ambiguity. Research suggests users are most interested in when the underlying data was last refreshed

Updated 18/09/24 Before this can be implemented, UCD need to agree on how to implement it and UI designs to be updated if required

User Story As a data user, I want to see clear and unambiguous information about when the underlying data was last refreshed, so that I can determine whether the data is current, reliable, and aligned with my expectations for timeliness.

Acceptance Criteria

• Display "Last Refreshed" for the underlying data in a prominent position. This date reflects the last time the source data was updated, not just when it was ingested or indexed in the catalog. (How can this be clearly communicated?)
• If applicable, also show a "Last Updated" date for metadata changes, (clearly distinguishing it from the data refresh date.)
• Provide information about the expected refresh frequency of the dataset, so users can compare the actual refresh date with the expected update cycle - Refresh Period field?
• Clarify any difference between "update" (when data was last altered in the source) and "refresh" (when the catalog ingested the latest version), ensuring users can make informed decisions.(Is this necessary and how can this be done?)
• Indicate whether the dataset is authoritative or could lag behind, helping users understand if they need to seek out the latest version elsewhere. (Any ideas on how to do this?)

[markjefferson-gov]

Need to clarify:

• update vs refresh
• data source vs underlying data - how often is there a difference? is the difference significant?

Clarify and display refresh frequency at the same time?

See also potential need for first added date.

[alex-vonfeldmann]

re 'what is the difference' - my understanding is:

• some source or transformed data might be updated ad hoc

• some source or transformed data might have an expected update cycle (eg. quarterly official statistics, weekly model outputs), so it can comply with or fail that cycle -> users want to know when source data or transformed data was last changed (and whether that's in line with expectations)

• the metadata description might be ingested daily regardless of whether data has changed or not

• the metadata description might be updated ad hoc (eg. typo correction, change of data owner, etc) -> users might want to know that the metadata description has changed (and what has changed)