Facets must be orthogonal

What it is

Two facets are orthogonal when a value on one does not entail a value on the other. Color and size are orthogonal: red does not mean L. If type = laptop almost always entails size = portable, the second facet is not a new constraint; it is a shadow of the first. Orthogonality guarantees that each check cuts new information. Non-orthogonality guarantees that some checks are duplicate labour and some combinations are empty as a matter of logic.

Two dropdowns do not make two orthogonal facets. Different field names whose values strongly imply each other are still coupled.

Why it happens

Intersection is valuable only when the information is independent. If P(size | type) is already near 0 or 1, checking size barely changes the set, while people believe they have narrowed again. Worse is reverse entailment: “infant” is selected and “alcohol” remains clickable; the intersection is semantically empty, not merely out of stock. Non-orthogonality collapses “no inventory” and “this sentence contradicts itself” into the same zero result.

Orthogonality is not statistical independence (the real world is always correlated). It is non-entailment in the type system: every combination of values is legal; emptiness should come from current stock, not from the taxonomy fighting itself.

Studying it

Measure entailment; do not only watch whether facets are used.

• Paradigms: estimate conditional probability and mutual information between facets on the corpus; find value pairs that nearly determine each other. On tasks, compare orthogonal facets with deliberately coupled ones for narrowing efficiency and for how people explain empty results.
• Independent variables: coupling of facet pairs, whether shadow facets are hidden in the UI.
• Dependent variables: set reduction from one extra check, the share of empty results that are logical impossibilities versus zero stock, whether people think the system is broken.
• Methodological note: corpus correlation (winter and down coats) is not definitional coupling (winter entails down coats). The first is inventory structure; the second is a classification error. Keep them apart. Experts often slice facets by internal modules, and those module boundaries are often not orthogonal.

Where it stops holding

Geographic containment (country > region > city) is entailment by nature and should be one hierarchical facet, not three “independent” facets pretending to be orthogonal. Time granularities (year / quarter / month) are coarsenings of one axis, not three facets. Marketing tags (“spring arrivals”) often smuggle in season and on-shelf status, coupling with “season” and “listed at”—delete the marketing facet or demote it to a non-constraining badge.

Applying it

• Before launch, check every facet pair for entailment: is there an A such that B is almost never worth checking. If so, merge, nest, or delete the shadow.
• Show legitimate correlation with counts (many down coats in winter). Do not disable options as if they were definitional.
• Write into each facet’s value definitions which other facet it does not entail, so later business rules cannot be stuffed into the taxonomy.
• Verify by constructing combinations that ought to be semantically legal. Even if stock is currently empty, the taxonomy must not mark them impossible. If the UI extinguishes a combination before a check, ask whether the reason is zero stock or two facets in a fight.

Related

• Within the group: G1.06.1 Facets allow independent filtering on several dimensions · G1.06.3 Empty facet combinations should be suppressed in advance
• Adjacent: G1.03 Taxonomy and hierarchy · G3.10 Faceted navigation · G1.05 Metadata
• Search terms: orthogonal facets · facet independence · coupled dimensions