Catalog Metadata Quality: A Practical QA Checklist

Decide what the checklist is allowed to prove

A metadata quality check answers a narrow question: does this record satisfy the rules this catalog already wrote? It does not prove that the record is true in the world, that a customer will understand it, or that a supplier sent their best file. Those are different questions. Mixing them produces a green status that nobody can explain.

Write the rules before the file arrives. A rule invented while looking at a failing record is a negotiation, not a check. The check compares the record with the rule. The negotiation, if you need one, happens later and changes the rule for the next record.

This page is a practical checklist for that comparison. Names, formats, and locale tags are how values get into one form before the check. A taxonomy that can add concepts is how controlled values stay stable. This page assumes those rules exist and asks whether the record follows them.

Separate required fields from optional fields

A required field blocks release when it is empty or invalid. An optional field may stay empty. If the catalog cannot say which is which, every empty cell looks like a defect, and people invent values to make the cell look finished.

Make the list explicit. For each field, record the name, whether it is required, what “valid” means, and what an empty value means. “Valid” might be “a date in year-month-day form” or “a term from the current vocabulary.” It should not be “looks reasonable.”

Optional does not mean unimportant. It means the record can ship without it, and downstream systems must tolerate the absence. If a storefront cannot render a record without a particular optional field, that field is required and the list is wrong. Fix the list. Do not quietly treat the gap as a content problem.

DCMI Metadata Terms, issued 20 January 2020, includes a fifteen-element set in the /elements/1.1/ namespace: contributor, coverage, creator, date, description, format, identifier, language, publisher, relation, rights, source, subject, title, and type. That list is a published example of shared labels for describing resources. It is not the required field list for a product or content catalog. A catalog may adopt some of those ideas, ignore others, and add fields DCMI does not define. The useful habit is the one DCMI also makes visible: name the terms, and do not pretend an unnamed local field is part of a shared set.

Completeness is not the same as correctness

A complete record has every required field filled with a value the rule accepts. A correct record has values that match the thing the record describes. The checklist can test the first. It cannot, by itself, test the second.

You can check that a title is present, within the length rule, and free of the control characters your format forbids. You cannot check that the title is the one the supplier intended unless you have a second source you trust for that comparison. When you do not, say “present and well formed.” Do not say “accurate.”

The same split applies to classification. The checklist can confirm that a subject value is in the controlled vocabulary. It cannot confirm that a person would have chosen that subject. A wrong-but-valid code will pass a completeness check. That is a reason to keep a separate review for high-risk fields, not a reason to call the automated check a failure.

W3C Best Practice 6, in the Data on the Web Best Practices recommendation of 31 January 2017, says to provide information about data quality and fitness for a particular purpose. The recommendation is about datasets on the web. The operational point that travels is narrower: write down which uses the record is fit for, and which defects you already know. A catalog that only shows a pass mark hides the difference between “required fields are present” and “a specialist compared this with the source.”

Run the check in a fixed order

Use the same order every time so a failure is comparable with the last one.

1. Identify the record and the rule set version. A check against last month’s required fields is not a check against today’s.
2. Reject the record if the identifier is missing or collides with another record. Collisions are handled in the guide to duplicate, missing, and conflicting records. Do not “fix” them inside a metadata pass by keeping whichever row was opened first.
3. For each required field, record pass or fail, plus the rule that failed. “Bad metadata” is not a result.
4. For each optional field, record present, empty, or invalid. Invalid optional values do not become valid by being optional. Either repair them or clear them and record why.
5. Confirm controlled values against the vocabulary version named in the rule set, not against a copy someone pasted into a ticket.
6. Write the result where the release owner can read it without opening the editing tool.

Stop at the first blocking failure only if the team has agreed that later checks are wasted effort. Otherwise finish the list. A record that fails five rules should show five failures. Finding them one release at a time is how a catalog appears to get worse after each fix.

This table scrolls sideways on a narrow screen.

Record the failure where the next person will see it

A failed check needs a destination. If it lives only in a chat message, the release owner will not see it, and the same record will fail again next week with no memory of the first failure.

Keep four pieces: the record identifier, the field, the rule, and whether the record is blocked. Add the source file name when the value came from intake. Do not add a guess about who was careless. The check does not know that, and a guess becomes a false record of its own.

When the rule itself was wrong, correct the rule and say so. A field that failed yesterday and passes today because the rule changed is not a mysterious data repair. The log should show the rule change.

What a shared element set does not decide

Best Practice 1 of the same W3C recommendation says to provide metadata for people and for applications. DCMI’s terms show one way a community published a shared set. Neither document chooses your required fields. A catalog that copies the fifteen Dublin Core elements and stops will still be missing the commercial, rights, or asset fields it actually releases on. A catalog that ignores them and never writes its own list has the same problem from the other side.

Use an external set when it names a concept you already need and you are willing to keep the meaning. Do not import it as decoration, and do not cite it as proof that your local checklist passed.

When a metadata check is enough

When can an empty field ship?

When the field is optional and downstream systems are required to tolerate the absence. If the storefront breaks without it, the field is required.

When needed: While the field list is being written, and again when a channel starts depending on a field.

When does a valid value still need a person?

When the risk is that the value is the wrong member of a valid set: a real category code on the wrong record, for example. The checklist can only prove membership.

When needed: On fields the catalog has marked as high-risk, before release.

When should the checklist change?

When a rule changes, not when a single record is inconvenient. Update the rule version, then run the check against the new version.

When needed: Before the next release that depends on the new rule.

Tags: checklistcompleteness

Sources

1. DCMI Metadata Terms — Dublin Core Metadata Initiative
2. Data on the Web Best Practices — W3C