Tagging taxonomy
Purpose: Use cq:tags for classification, filtering and search — and keep the taxonomy governed.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Listings, filtering, related-content features |
Mechanics
Tags are content (cq:Tag nodes) under /content/cq:tags/<namespace>/…, referenced from pages/assets/fragments via the cq:tags property (array of tag IDs like phi:plans/hospital/gold).
/content/cq:tags/phi/
├── plans/
│ ├── hospital/ ← phi:plans/hospital
│ │ ├── gold ← phi:plans/hospital/gold
│ │ └── silver
│ └── extras
└── audience/
├── families
└── singlesWhat tags are for (and not)
| Good use | Wrong tool |
|---|---|
| Cross-cutting classification (audience, theme) | Encoding the site hierarchy again |
Query/filter predicates (tagid in QueryBuilder) | Storing data values (premium=289 as a tag) |
| Related-content lookups | Access control |
| DAM asset discovery | Workflow state |
QueryBuilder: tagid=phi:plans/hospital/gold&tagid.property=jcr:content/cq:tags — tag predicates are indexed and hierarchical (searching a parent tag matches descendants when using the right predicate options).
Governance
- Namespaces per domain (
phi:), created deliberately; free-form tag creation by authors should be off for controlled taxonomies. - Renaming/moving tags updates the taxonomy but referenced IDs persist — plan taxonomy like a schema.
- A taxonomy owner (content ops) approves additions; engineering consumes, doesn't invent, tags.