Metadata underpins filtering, sorting, and relating
Aliases: descriptive metadata · filter sort relate · structured description
What it is
Metadata is a structured description of content: type, author, date, status, audience, subject terms. Filters narrow a set by field values, sort orders a set by a field, and relatedness pulls objects together through shared fields. Without those fields, on-screen filters, sort controls, and “related” modules have nothing computable to consume and can only pretend. Metadata is not decorative tagging on a page. It is the data layer that lets the same collection be sliced, ordered, and linked for different tasks.
Titles and body text can be read by a person. They cannot be reliably computed by a filter. Fields can.
Why it happens
A browse tree offers one path at a time. Metadata turns an object from “lives in a folder” into “carries a set of queryable attributes,” so the same object can be ordered by date, filtered by type, and joined by subject without moving its primary location. Filtering intersects in attribute space; sorting imposes a total order on one dimension; relating neighbours on a shared value. All three consume the same fields. Once a field’s meaning is vague (“date” as created, published, or revised), all three lie together.
People can perform the three operations only while field names and values are stable, and while the on-screen controls are bound to those fields rather than to a second, ad-hoc rule.
Studying it
Make the mapping between UI controls and underlying fields checkable; do not only test whether “filtering feels good.”
- Paradigms: when a task needs filter, sort, or relatedness, record the cut people expect; then compare it with fields the objects actually have. Field-ablation: drop one field and see which task class collapses first.
- Independent variables: the available field set, whether field semantics are disclosed, whether relatedness is shared-field or a recommender.
- Dependent variables: whether the task can finish without falling back to whole-tree browsing, whether sort matches what people mean by “recent / relevant,” whether related hits can be explained by a field.
- Methodological note: low filter use in logs may mean the fields do not support the cut people need, not that people “don’t like filtering.” A relatedness module that cannot point to a shared field must not be counted as metadata-based relating.
Where it stops holding
Pure linear reading (a long article, a checkout) does not need these three operations; bolted-on filters become empty controls. Live objects (an ongoing call, a sensor stream) have fields that keep changing; “current” sort and relatedness jitter and need a time window, not a static catalogue. Machine-learned similarity can patch sparse fields, but it is not metadata: it is not explainable, not hand-correctable, and it fails differently.
Applying it
- For each object type, list the fields that filter, sort, and relate will consume. Do not draw a control for a missing field.
- Write one user-facing definition per field (“date = published at”). Filter, sort, and related share that definition.
- Related modules should show what is shared (same author, same subject), not only “you might also like.”
- Verify by turning off full-text search and completing three typical tasks with only filter, sort, and related. Any class that cannot finish still lacks metadata; the control is not merely unattractive.