When Is an Ontological Approach Not the Right Fit for Sharing and Reusing System Knowledge in Design and Development?
š§ When Is an Ontological Approach Not the Right Fit for Sharing and Reusing System Knowledge in Design and Development?
Ontologies promise knowledge integration, traceability, reuse, and machine reasoning across the full engineering system lifecycle. From functional models to field failures, ontologies offer a way to encode and connect it all.
š„ However, ontologies are not a silver bullet.
There are plenty of scenarios where an ontology is not just unnecessary, it might actually slow you down, confuse your team, or waste resources.
So when exactly does the ontological approach become more burden than benefit? Based on my understanding and current work in this space,
š For engineering design, it's important to recognise situations where adopting a semantic model is not the most effective approach:
1. When tasks are highly localised and routine
If you're just tweaking part drawings, running standard FEA simulations, or updating well-established design details, then the knowledge already lives in your tools and practices. Adding an ontology might feel like installing a satellite dish to tune a local radio station.
2. When terminology is unstable or fragmented
Ontologies depend on consistent language. If every department speaks its own dialect, and no one agrees on terms, you can't build shared meaning. Youāll end up formalising confusion instead of clarifying it.
3. When speed matters more than structure
In prototyping labs, testing grounds, or urgent production lines, agility rules. Engineers solve problems fast, often through direct collaboration. Taking time to define formal semantics? Not always practical. Sometimes the best model is a whiteboard and a sharp marker.
4. When the knowledge wonāt be reused
Not all projects aim for longevity or cross-team learning. If you're building something once, for one purpose, with no intention of scaling or sharing, skip the ontology. Itās like building a library catalog for a single book.
5. When the infrastructure isn't there
Ontological engineering isnāt magic. It needs tools, training, and people who understand the stack. If your team lacks the skills or platforms, even the best-designed ontology will gather dust in a forgotten folder.
Use the Right Tool for the Real Problem
Ontologies are powerful, but not sacred. They shine when you need to connect knowledge across domains, ensure long-term traceability, or enable intelligent automation. But theyāre not a requirement for every task just because theyāre clever.
The real challenge is not whether to use ontologies, but knowing when they genuinely improve clarity, consistency, and collaboration, and when they just complicate the obvious.
š§ Feedback and critique are welcome; this is a living conversation.
Felician Campean
#KnowledgeManagement #SystemsEngineering #Ontology #MBSE #DigitalEngineering #RiskAnalysis #AIinEngineering #OntologyEngineering #SemanticInteroperability #SystemReliability #FailureAnalysis #KnowledgeIntegration | 11 comments on LinkedIn
When Is an Ontological Approach Not the Right Fit for Sharing and Reusing System Knowledge in Design and Development?