Metrics v2 — Overview#
Unreleased preview — metrics v2
This section describes metrics v2, which is not yet released. Current piveau deployments run metrics v1 (documented in the pages above). The content here is published in advance so operators and publishers can prepare; details may still change until the release.
Why v2#
Metrics v1 scores datasets by summing fixed, absolute point values (e.g. "keyword usage" is worth 30 points) into five weighted dimensions, using a "best distribution" selection to represent the dataset as a whole. This worked, but it made the scoring model hard to reason about, gave Data Services no first-class place in the model, and tied scoring to a fixed points scale that is difficult to extend or customize.
Metrics v2 replaces this with a simpler, more transparent model: every checked property carries an importance-derived weight, every check produces a binary result (pass/fail, no partial credit), and scores roll up from the checked properties through distributions and data services to the dataset, and from datasets to the catalogue. The methodology is described in full in Scoring methodology.
The pipeline in v2#
The same pipe segments exist in v2, but their responsibilities are sharper:
The following diagram shows how a dataset moves through the v2 pipeline, from harvesting to the catalogue's read API:
flowchart LR
A["Incoming dataset from harvesting"] --> B["Annotator: boolean property checks"]
B --> C["Accessibility: URL reachability via HTTP HEAD"]
C --> D["Score: entity scores + dataset final"]
D --> E["Hub / triplestore: metrics graphs stored"]
E --> F["Cache: aggregates catalogues"]
F --> G["REST API / UI"]
H["Validating SHACL"] -.->|"validation report, not scored"| E| Service | Role in v2 |
|---|---|
| Annotator | Evaluates boolean property checks against Datasets, Distributions, and Data Services (presence, valid URL/URI, controlled-vocabulary membership). |
| Accessibility | Checks the technical reachability of access/download/endpoint/landing-page URLs with an HTTP HEAD request, and writes a binary reachable/unreachable result. |
| Score | Condenses the boolean checks into numeric scores per entity, and computes the dataset-level roll-up (including embedded Data Services) into a single final score. |
| Cache | Aggregates final scores and per-metric coverage across a catalogue (or country, or the whole platform) and serves them over a REST API. |
| Validating SHACL | Unchanged: still validates metadata against the DCAT-AP SHACL shapes and still produces a validation report, but its result is no longer folded into the quality score (see below). |
Data Services (dcat:DataService) become first-class scored entities in v2, whether they are
embedded in a distribution (via dcat:accessService) or stand alone at the catalogue root.
What changes compared to v1#
| Aspect | v1 | v2 |
|---|---|---|
| Weighting | Absolute points per property (e.g. keyword usage = 30 points) | A layer/weight scheme: Mandatory = 1.0, Recommended = 0.5, Optional = 0.25 |
| Maximum score | Five dimension maxima summing to 405 points | 7.5 points per entity (Dataset, Distribution, and Data Service each have their own 7.5-point property set) |
| Dimensions | Five dimensions (including Contextuality), each scored and reported | Four FAIR dimensions (Findability, Accessibility, Interoperability, Reusability); Contextuality is dropped, and dimensions are internal labels only — no longer aggregated or reported |
| Data Services | Not scored | First-class scored entities, whether embedded in a distribution or standalone at the catalogue root |
| Dataset score | The single "best" distribution is selected to represent the dataset | The dataset's own score is averaged together with the average of its distributions' scores and (if any) its data services' scores |
| Catalogue score | Aggregated from stored measurements | The average of every dataset's final score plus every standalone Data Service's score |
| Accessibility check | A range of HTTP status codes (200–399) counts as reachable | Binary: only a 2xx response counts as reachable; everything else (including redirects) counts as unreachable |
| Deprecated distributions | Not specifically handled | Ignored entirely — not evaluated, not scored, excluded from coverage; a dataset whose distributions are all deprecated is excluded from catalogue aggregation |
| DCAT-AP compliance (SHACL) | Scored as part of the Interoperability dimension | Still validated and reported, but no longer contributes to the score |
| Scale / rating bands | Bands derived in the UI from the point total | Scores are raw numbers in the 0–7.5 range; no rating bands are produced by the metrics services |
Preparing for v2#
A few things are worth planning for ahead of the release:
- API payload shapes change. The v2 cache API returns raw 0–7.5 scores and per-metric coverage percentages instead of v1's dimension-grouped point totals — any integration reading the current metrics API will need to be updated. See Data model and interfaces.
- Dimension-based filtering disappears. Because FAIR dimensions are internal labels only in v2, any workflow that filters or displays metrics by dimension (e.g. "show me the Contextuality score") will need to be reworked around the new per-property and per-metric results instead.
- The score scale changes entirely, from v1's points scale (maximum 405, dimension-weighted) to v2's raw 0–7.5 range per entity. Any dashboard, threshold, or alert tied to the old scale needs to be recalibrated — the two scales are not convertible into one another.
- v1 metric history is not migrated. v2 is a hard cutover: when a deployment switches on the v2 pipeline, it starts scoring and aggregating fresh. Historical v1 scores remain available as a record of the past, but there is no automatic conversion into v2 numbers.
- If you customize which properties are checked or how heavily they are weighted, see Configuring and customizing the metrics.