PicaJet

Reference Glossary

Ontology

A formal model of a domain's concepts and the specific relationships between them (not just hierarchy, but ties like "depicts" or "part of") that lets software infer connections a flat taxonomy can't.

Why it matters in a DAM

An ontology is what lets a DAM's search or recommendation engine reason across relationships instead of just matching a category path — for example, encoding that a person is "CEO of" a company, so a search for "leadership team" can surface a headshot tagged only with an individual's name, without a human ever manually re-tagging it "leadership." This is the layer behind genuinely semantic or AI-assisted DAM search, as distinct from search that's just matching against a taxonomy or keyword list.

A worked example

Entity Jane Alvarez
Relationship: role_at Alvarez Photography
Relationship: depicted_in IMG_4471.CR2, IMG_4502.CR2
Inferred "Alvarez Photography team" query can surface IMG_4471 and IMG_4502

Common mistake

Vendors and teams label any tag hierarchy an "ontology," but without genuine typed relationships between entities — not just broader/narrower category nesting — no system can actually perform the inference the term implies; what's marketed as "ontology-powered search" is often just a taxonomy with better branding.

The commonly cited definition of ontology in information science comes from Thomas Gruber’s 1993 paper, which describes an ontology as “an explicit specification of a conceptualization” — a deliberate enumeration of the concepts in a domain and the constraints on how they relate, made explicit enough for software to process rather than left implicit in a person’s understanding. The definition was later refined by other researchers to emphasize that a genuine ontology is also formal (machine-processable) and shared (agreed upon across a community), not just one team’s private schema.

Technically, ontologies in DAM and broader digital systems are usually implemented using W3C’s Web Ontology Language (OWL), a W3C Recommendation since February 2004, built on top of the Resource Description Framework (RDF) that also underlies XMP’s data model. OWL lets a system define classes, individual entities, and typed properties between them — and, critically, lets a reasoning engine derive new facts from those relationships rather than just retrieving what was explicitly stored.

Full ontology-driven metadata is still uncommon in mainstream DAM deployments — it requires modeling work well beyond setting up a category tree, and most organizations get adequate search performance from a well-maintained taxonomy and controlled vocabulary alone. Where it does show up is in large media libraries and knowledge-graph-backed AI search features, where entity relationships (people, places, products, events) need to be queried, not just their labels.

Frequently asked

How is an ontology different from a taxonomy?

A taxonomy is hierarchy only — broader and narrower categories. An ontology is a formal model of a domain's concepts plus specific typed relationships between them, like 'depicts' or 'part of,' letting software infer connections a flat taxonomy can't.

What can an ontology let a DAM's search do that a taxonomy can't?

It lets search or recommendation reason across relationships — for example, encoding that a person is 'CEO of' a company, so a search for 'leadership team' can surface a headshot tagged only with an individual's name, without anyone manually re-tagging it 'leadership.'

Is every DAM feature marketed as ontology-powered actually an ontology?

Often not. Vendors and teams label any tag hierarchy an 'ontology,' but without genuine typed relationships between entities, not just broader/narrower nesting, no system can actually perform the inference the term implies.

What does an ontology add on top of a metadata schema?

A schema defines what fields exist; an ontology defines how the concepts those fields represent relate to each other, enabling inference rather than just structured storage and lookup.

What's a practical example of ontology-driven inference in a DAM?

Surfacing a headshot tagged only with a person's name in a 'leadership team' search, because the ontology encodes that the person holds a 'CEO of' relationship to the company — a connection a flat taxonomy has no way to represent.

How can a team tell if their DAM's ontology is genuine?

By checking whether it defines actual typed relationships between distinct entities, not just category nesting labeled with ontology language. If it only supports broader/narrower browsing, it's a taxonomy regardless of what it's called.

Sources