Structure

Metadata and Catalogues: Describing What You Have

Metadata is the part of a digitisation project that everyone agrees is important and nobody wants to do. It is also the part that determines whether the collection can be found, filtered, cited or combined with anything else. A perfectly scanned, beautifully structured collection with no description is a warehouse with no index.

Start with the minimum that is actually maintainable

The commonest failure is designing an ambitious schema, populating it fully for the first fifty items, and then abandoning it. A collection with rich metadata on 3% of items and nothing on the rest is worse than one with modest metadata on everything, because it cannot be searched consistently.

Decide what a record must have to be findable and citable, make those fields mandatory, and make everything else optional and clearly so. For most reference collections the mandatory set is small: a stable identifier, a title, a date, a type, a source statement and a rights statement. Six fields, complete across the whole collection, will outperform thirty fields completed sporadically.

Borrow a schema

Inventing a metadata schema is almost never the right call. Established vocabularies exist, are documented, and are understood by tools you have not chosen yet.

Dublin Core is the sensible default for general collections — deliberately small, widely supported, and easy to map into something richer later. Library-domain material may warrant MARC or its successors, though the cost is real and only justified if you actually need to exchange with library systems. For anything published on the web, adding schema.org markup costs little and improves how the collection is understood by search engines.

The practical approach: hold your records in whatever internal shape suits you, and treat published schemas as export formats. Then you can serve several without contorting the internal model.

Authority control, minus the ceremony

Authority control means that the same person, place or subject is referred to the same way everywhere, and that variants map to one canonical record. Without it, a search for a person finds a third of their material, because the rest is filed under a different spelling.

The lightweight version is achievable by any small project: keep a separate list of names and subjects with stable local identifiers, have records point at those identifiers rather than repeating strings, and record known variants against each authority record. Where an external authority exists, store its identifier too — this is what later allows your collection to be linked to others without a reconciliation project.

Local fields multiply, and that is fine if you label them

Every real collection needs fields no standard provides: a shelf mark, a condition note, a scanning batch, an internal status. Trying to force these into standard fields corrupts the standard ones — this is how a subject field ends up containing workflow notes.

Keep local fields clearly separated and documented as local. They should never be exported as if they were standard, and they should be listed somewhere with a plain-language description of what each means and who maintains it. That document is worth more than it looks: it is what makes the collection intelligible to whoever inherits it.

Describe the collection, not only the items

Item-level description without collection-level description leaves readers unable to judge what they are looking at. A collection record should answer: what is this, what does it cover, what does it deliberately exclude, how complete is it, where did it come from, and how current is it.

The exclusions and gaps matter as much as the contents. A user who knows a collection covers one region to 1950 can use it confidently. One who does not will assume absence means non-existence, and draw a false conclusion.

Rights, stated plainly

Every record needs a rights statement, and "unknown" is a legitimate and useful value when true. Undocumented rights status is the single most common reason collections cannot be reused, aggregated or preserved elsewhere — an aggregator that cannot determine the licence will simply decline the material. This is developed in open licensing for archives.

Metadata is maintenance, not a phase

Description is often planned as a stage that finishes. It does not. Records get corrected, authorities merge, new material arrives, standards move. Build for edits: identifiers that never change, a modification date on every record, and a way to correct a value in one place and have it propagate.

The structural layer beneath this is covered in structuring an encyclopaedia; the addressing layer that makes records citable is in link rot and permanent URLs.