Data follows intent
The data should not dictate the ontology, unless the data exactly reflects your focus. In this sense, most ontology designs start in the wrong place.
You look at your documents, your database schemas, your existing data and you build an ontology that reflects what’s there. It feels empirical and safe, but often it’s also backwards.
An ontology is not a description of your data, rather a statement of what you care about. It defines the concepts, relationships, and distinctions that are meaningful to you not the ones that happen to be easiest to extract.
If you run a pharmaceutical company, your ontology should encode what matters to drug development: targets, mechanisms, adverse events, trial phases, regulatory pathways. Not whatever noun phrases your extraction pipeline surfaced most frequently.
If you run a law firm, your ontology should reflect the structure of legal reasoning (jurisdiction, obligation, precedent, party) not the entity types your extraction model was trained on.
Data follows intent. Ontology precedes data.
I think people go from data to blueprint because it’s easier to let engineering deal with ontologies, letting the data talk via extraction. On the other hand, defining what matters as a company (division) entails meetings, business goals, difficult questions, sometimes difficult people. Ontology design is a knowledge-elicitation exercise, not a data-mining exercise. The right people in the room are domain experts and decision-makers, not data engineers (or at least not only engineers).