Metadata schema choices for content libraries
Structured metadata only works when it matches how people actually retrieve content. A neat schema diagram means little if search returns the wrong item, filters behave oddly, or the catalogue treats one card as three different things. Tarot libraries make that plain: the same object can be a card, a trump, a named figure, or a deck-specific special case.
Start with the retrieval path, not the schema diagram
The retrieval path tells you what the library must answer quickly. A self-hosted wiki, content library, or card catalogue usually needs a few simple questions first: title, deck, suit or arcana group, numbering, and any special role. If those fields are missing or vague, the rest of the metadata schema becomes decoration.
Tarot is a useful test case because classification shifts across traditions. The Fool may sit inside the Major Arcana in one reading model, while in game contexts it behaves as a special card with its own rule set. Historic decks also treat it differently in title and depiction. A catalogue that stores only one narrow label ends up hiding the differences that matter for search indexing.
That is the first design choice: store the retrieval facts separately from the interpretive label. One field can hold the canonical title, another the deck-specific name, another the role in the system. This keeps cataloguing stable when the same item changes meaning across traditions.
Map fields to search, filters, and the content model
Every field in structured metadata should earn its place in search or filtering. If a field will never drive a query, sort order, or content relationship, it is usually noise. A useful metadata schema maps cleanly to the content model: what the item is, where it belongs, and how it can be found again.
For tarot card catalogues, numbering deserves careful handling. The Fool may appear unnumbered, as 0, or rarely as XXII. A rigid integer field cannot hold that variation without losing meaning. A better model separates display number from ordering logic, so a catalogue can sort cards sensibly while preserving the original deck notation.
The same applies to names. Tarot of Marseilles uses Le Mat, Italian decks use Il Matto, and other systems use different labels. Search indexing should be able to find all of them without forcing a single preferred spelling into the record. A title field, an alias field, and a language or tradition field do more work than a single free-text note.
Filters need the same discipline. If a user wants to narrow by deck family, iconography, or game tradition, those values should exist as structured fields rather than tags buried in a description. Free text is useful for commentary, but it is poor at dependable retrieval. One misspelt note is enough to make a card vanish from search.
Decide where taxonomy stops and free-form metadata begins
Taxonomy works best where the library needs consistency. Suit, arcana group, deck family, language, and card role are all good candidates because they form stable categories. Once the category begins to describe interpretation, commentary, or edge-case context, free-form metadata usually handles it better.
The boundary matters because tarot material carries a lot of version-specific detail. One deck can depict the Fool as a jester, another as a bard, another as a young man at a precipice with a dog and a white rose. Those iconographic details are not the same kind of field as the card’s function in a game or reading system. If they are forced into one taxonomy, the catalogue becomes brittle.
A practical split is to keep the catalogue’s core taxonomy small and predictable, then place descriptive variation in structured notes or tagged attributes. The taxonomy says what kind of thing it is. The metadata says what makes this instance different. That keeps self-hosted wiki pages readable without turning every page into a taxonomic incident.
Test the schema against a live library and tighten the edges
A metadata schema looks tidy until real records hit it. Load a few awkward tarot entries into the library: a deck with unnumbered cards, one with zero-based numbering, one with alternate titles, one with unusual iconography. Then check whether search indexing still finds the card, whether filters still make sense, and whether the content model still holds together.
The bad signs are obvious. Search misses the card because the title was stored only in one language. Filters break because numbering was stored as text in one place and a number in another. Taxonomy starts swelling because every exception was turned into a new category. That is usually where the catalogue stops being a catalogue and starts being a pile of admin.
Tighten the edges by changing the schema, not by asking users to remember clever rules. If a field needs sorting, make it sortable. If it needs alias matching, store aliases. If it only describes a picture, keep it out of the main taxonomy. A self-hosted content library stays usable when structured metadata reflects the mess it has to hold, not the clean diagram drawn before anyone imported a record.
