A dataset record, before and after: fixing public data metadata

A dataset is only as useful as the record that describes it. If the title is cryptic, the licence is a sentence in a PDF and the download link has moved, people searching a national portal or data.europa.eu won’t find it, or won’t trust it when they do. The European standard for these records is DCAT-AP, the application profile of the W3C Data Catalog Vocabulary, explained in the guide to DCAT-AP and data catalogues.

Rather than repeat the rules, this piece takes one illustrative record and fixes it.

The record before

Imagine a county council has published its bus stop data like this:

Nothing here is unusual. Every field is filled in, and every one of them makes the data harder to find or use.

Seven fixes

1. A title and description a person would search for

Title and description are mandatory for a dataset in DCAT-AP, and they must carry a language tag.¹ “Bus stops in the county: names and locations” says what the data is. The description should say what each record covers, how often it is updated and anything a reuser must know, such as whether temporary stops are included.

2. One dataset, several distributions

The CSV file and the JSON feed are the same data in two forms. DCAT separates the dataset, as an abstract idea, from its distributions, the forms it is offered in.³ Merging the two records into one dataset with two distributions removes a duplicate and tells users they are getting the same data either way.

3. A licence from the vocabulary, not a sentence

DCAT-AP recommends using the Publications Office’s licence vocabulary where national law allows, rather than local wording, because the same licence written different ways is hard for machines and people to recognise.¹ A link to the controlled entry for the open licence you use answers the reuse question instantly.

4. A format from the controlled list

“Spreadsheet” could mean anything. data.europa.eu’s metadata quality assessment checks whether format and media type values come from the controlled vocabulary.² “CSV” from the file type list is unambiguous.

5. Links that work

The quality assessment checks whether selected links actually work, and only a successful HTTP 2xx response counts as accessible.² Where a file can only be reached through a web page, DCAT says that page should be given as the distribution’s access address.³ Better still, give the file a stable address that doesn’t change with each upload.

6. A theme, keywords and coverage

The EU’s data theme vocabulary is the mandatory code list for classifying datasets by theme, and keywords, geographical coverage and time coverage are among the recommended properties.¹ Tagging the dataset with the transport theme and the county’s area is what puts it in front of someone filtering for transport data in that region.

7. A contact, a publisher and a version

Contact point and publisher are recommended properties for a dataset.¹ W3C’s Data on the Web Best Practices also asks publishers to provide version information, so reusers can tell which release they hold.⁴ A shared team mailbox outlasts any individual’s address.

The record after

What a quality score doesn’t tell you

Better metadata raises a record’s score in the quality assessment, which weights mandatory properties more heavily than recommended and optional ones.² But the assessment judges only the metadata, not whether the data itself is correct or complete.² A perfect record for a stale file is still a stale file.

That is why the fixes above sit alongside the habits in linked open government data: stable identifiers for the things in the data, and a clear process for keeping it current.