Data & Data Science
Data quality is not a single property that can be read from a dataset. A defensible assessment defines which quality dimension matters for the concrete use, how it is measured, against what reference it is evaluated and which records or fields are included in the denominator.
Short answer
Completeness, consistency, accuracy and currency describe different properties. A dataset can be complete but inaccurate, internally consistent but outdated, or current but structurally incomplete. The examination therefore reports dimensions and measurements separately instead of collapsing them into one quality score.
Metrics require operational definitions. A percentage of missing values is meaningful only if the relevant field population and treatment of NULL, empty text, default values and semantically unknown values are specified. Accuracy requires an appropriate reference; plausibility rules alone cannot establish that a value is true.
1. Define the subject, quality dimension and use context
Quality dimension and metric must be separated
The examination starts with the concrete dataset and the decision or process for which quality is relevant. The same data may be adequate for one purpose and inadequate for another. A customer table used for aggregate regional counts has different critical attributes from the same table used for individual billing or identity matching.
A quality dimension names the property under consideration; a metric specifies how that property is measured. For example, completeness may be operationalised as the proportion of required records with a non-missing value in a defined field. The numerator, denominator, exclusions and time reference must be documented.
The empirical framework by Wang and Strong is useful for understanding that data consumers perceive multiple quality dimensions, but it is not a universal catalogue of pass/fail thresholds. Thresholds must be justified for the concrete examination context.
2. Examine completeness and missing values
Field completeness and population completeness are different
Field completeness asks whether expected attributes are populated in existing records. Population completeness asks whether the records that should exist are present at all. A table can have 100 percent non-null values and still be incomplete if an entire source period or customer group was omitted.
Technical encodings of missingness vary. SQL NULL, an empty string, zero, a sentinel such as -999 and a domain value such as “unknown” are not equivalent. Before counting missing values, the examination determines which representations are technically and semantically treated as missing.
Missingness patterns are also informative. Concentration by source system, time period, device type or processing stage can indicate an extraction or transformation problem that a global missing-value percentage would conceal.
3. Separate consistency, accuracy and plausibility
Internal consistency does not prove factual correctness
Consistency can be examined through cross-field rules, key relationships, duplicate constraints, date ordering and agreement between related tables. A record can satisfy every internal rule and still contain an incorrect real-world value.
Accuracy requires a reference that is sufficiently independent and appropriate for the property being checked. Depending on the task, this can be a source document, a trusted system of record, a calibrated measurement or a manually verified sample. The reference itself must have a stated status and limitations.
Plausibility and validity checks detect values outside expected formats, ranges or combinations. They are useful for anomaly detection but should not be described as accuracy proof. A plausible date can still be the wrong date.
4. Define currency and defensible quality metrics
Currency requires a justified time reference or threshold
A record is not simply “current” or “old” in the abstract. The examination identifies which timestamp represents creation, last update, source event or synchronisation and relates it to the use case. A weekly updated reference may be current for reporting but too old for a real-time transaction decision.
Metrics should expose their calculation basis. Reporting 96 percent completeness without the examined fields, denominator, exclusions and measurement date makes later reproduction difficult. The same applies to consistency violations, duplicate rates or age distributions.
The W3C Data Quality Vocabulary provides concepts for describing quality measurements and metrics. Its status is a W3C Working Group Note dated 15 December 2016; it is not a normative catalogue of quality thresholds. That source status remains explicit in the examination.
5. Use profiling, anomaly analysis and sampling carefully
Samples limit the reach of the conclusion
Data profiling can reveal distributions, cardinalities, missingness, duplicate patterns and unusual values across a full dataset. It is often a useful first layer before targeted validation against external references.
Where manual or reference-based checking is feasible only for a sample, the sampling method, population, selection criteria and sample size are documented. Findings from a convenience sample should not be generalized silently to the entire dataset.
Outliers and anomalies are investigated rather than automatically classified as errors. Rare but legitimate cases can be important, and a data pipeline can create systematic artefacts that affect many records without producing extreme numerical values.
6. Move from measurement to a bounded assessment
Measurements need a transparent derivation
The report links each quality statement to the dataset version, dimension, operational definition, measurement method, result and reference or threshold. Where the threshold comes from a business rule rather than a standard, that origin is identified.
Quality findings are also related to analytical impact. A missing field matters differently depending on whether the downstream method ignores it, imputes it or uses it as a target variable. The examination should therefore explain the technical consequence of relevant quality deficiencies.
No single dimension establishes overall fitness for purpose. The final assessment states which properties were measured and which remain outside the examination scope.
Is the technical conclusion sufficiently supported?
- Is the concrete dataset and intended use defined?
- Are quality dimensions named separately instead of merged into one generic score?
- Does every metric define numerator, denominator, exclusions and time reference?
- Are NULL, empty, sentinel and semantically unknown values distinguished?
- Is accuracy based on an appropriate reference rather than plausibility alone?
- Are full-dataset profiling and sampled checks clearly distinguished?
- Are thresholds justified by a documented source or use context?
- Are quality findings connected to their technical effect and stated limitations?
Constructed example
A quality dashboard reports “98% complete” for a customer dataset. The examination shows that the denominator includes only records successfully imported into the target system and therefore excludes an entire failed source batch. Field completeness inside the imported table is high, while population completeness for the intended period is lower.
A sample comparison with a source system also finds internally consistent but factually outdated addresses. The report separates completeness, consistency, accuracy and currency instead of averaging the findings into a single score.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Scientific original work Richard Y. Wang and Diane M. Strong, Beyond Accuracy: What Data Quality Means to Data Consumers, Journal of Management Information Systems 12(4) (1996), an empirical framework rather than a universal threshold catalogue. Open source.
- Technical primary source W3C Data Quality Vocabulary. Document status: W3C Working Group Note of 15 December 2016; not a normative threshold catalogue. Used for the distinction between quality dimensions, metrics and measurements. Open source.
- Normative specialist source ISO/IEC 25012:2008, a general data-quality model for structured data. The source article records that ISO reconfirmed this edition in 2025. Open source.
- Technical primary source W3C Data on the Web Best Practices, used as supplementary guidance for traceable data and quality information. Open source.
- Author technical literature Mathias Ellmann: Von Daten zu Lösungen in Data Science mit Python, background on data quality, preparation, profiling and reproducible Data Science processes. Open source.
- Author methodological framing Each quality dimension is operationalised with transparent numerator, denominator, missing-value rules, reference basis, threshold source and statement boundary.
Further reading
- Data as a Subject of Examination
- Data Preparation, Missing Values and Outliers
- Data Model, Schema and Integrity
- Statistical Analysis, Sampling and Reproducibility
Critical review and methodological limitation
Data-quality terminology can create a false impression of objectivity when a metric or threshold is not tied to a concrete purpose. The review therefore keeps dimension, metric, measured value, reference and assessment separate.
A high score in one dimension does not compensate automatically for a failure in another. The technical conclusion should remain tied to the measured properties and their demonstrated downstream relevance.
- Completeness: distinguish populated fields from whether the expected population is present.
- Accuracy: require an appropriate reference; plausibility and consistency are different tests.
- Currency: state the relevant timestamp, acceptable age and reason for the chosen threshold.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
Data Science & AI Assessments
Technical examination of data quality, model validity, reproducibility, bias, robustness and documented AI-system behaviour.
Explore this assessment service