A dataset needs more than samples and labels. Metadata describes properties of the data so a team can trace where it came from, how it changed, and whether it is still suitable for use. Useful attributes include when an event happened versus when it was processed and stored, its source, an associated user, and the software version used to process it. Changes to dataset structure or processing should be reflected in metadata. section 6.3
When a label source becomes unreliable
Suppose medical professionals label a large dataset, then one labeler is found to have fraudulent credentials. The team needs to stop using that person's labels promptly. Recording who produced each label makes the affected data identifiable; without that link, a problem with one contributor can put confidence in the whole dataset at risk. Source problems, regulatory interventions, and investigations of model errors create similar reasons to revisit metadata. section 6.3
Decide what to retain according to the dataset's likely quality and future uses:
- For sales forecasting, retain metadata about products, stores, and transactions alongside purchase and stock histories. section 6.7.1
- For photo search, retain seller information and description change dates. For clicks, retain user, seller, and search-session information; identifiers such as user_id, seller_id, session_id, and purchase_id preserve the ability to join records later. section 6.7.2
- Do not aggregate every user or seller attribute immediately. Preserve the links needed for later feature engineering, and use available context when filtering noisy clicks, including activity from scraping bots. section 6.7.2
Metadata can also become model input: an image's description and metadata need transformation before they can be used as features in a proposed photo-search system. That is a different decision from what to record for tracing and filtering. Keep both needs in view when designing a data pipeline for consistency, reproducibility, and availability. section 11.5.2 section 6.8
