Ontology development is not linear, but successful projects follow recognizable patterns. The workflow presented here distills lessons from the development of the aforementioned OCS and PRINCE2 ontologies, as well as other domain ontologies, into a pragmatic, iterative approach suitable for technical developers working with domain experts.
Begin not with classes but with questions. What must your ontology answer? Competency questions serve simultaneously as requirements specification and validation criteria.
For example, competency questions included:
"Which social processes influence political mobilisation?" "How do organisational structures affect innovation capacity?" "What demographic factors correlate with educational attainment patterns?" "Which causal relationships connect economic inequality to social movement emergence?"
These questions aren't merely illustrative—they're operational specifications. If the completed ontology cannot support SPARQL queries answering these questions, it fails its purpose. If it models concepts irrelevant to these questions, it's over-engineered.
Formulate 10-20 competency questions before proceeding. Involve domain experts; their questions reveal what knowledge representation must capture. Prioritise questions by importance—core questions drive initial development; peripheral questions guide later expansion.
Systematically list domain concepts. Review competency questions, domain literature, expert interviews, and existing classifications. Extract nouns (candidate classes), verbs (candidate properties), and adjectives (candidate qualities or restrictions).
Don't obsess over completeness at this stage—vocabularies expand naturally during development. Aim for 70-80% coverage of obvious concepts, then proceed.
Structure your vocabulary taxonomically. Which concepts are specialisations of others?
Use indented text files for initial hierarchy definition. This format balances human readability with tool processability. The text-file approach enabled version control, collaborative review, and automated generation whilst remaining accessible to domain experts reviewing class structures.
Key principles:
Specify object properties (relating instances) and data properties (attributing values). For each property, declare:
Domain and range: Which classes can participate? Overly broad domains/ranges reduce reasoning power; overly narrow ones create brittleness. Balance precision with flexibility.
Characteristics: Is the property functional, inverse functional, transitive, symmetric, asymmetric, reflexive, or irreflexive? Each object properties should be systematically declared per characteristics, enabling sophisticated automated reasoning.
Inverse properties: Define inverse pairs for bidirectional navigation. Well designed ontologies specifz inverses comprehensively‐'creates' / 'createdBy', 'influences' / 'influencedBy'‐ensuring query flexibility.
Annotations: Explain each property's intended meaning, usage examples, and domain significance. Future maintainers depend on these explanations.
Express domain constraints formally. Universal restrictions ("all Managers must supervise at least one Employee"), existential restrictions ("some Social_Movements involve Youth_Mobilisation"), cardinality restrictions ("every Person has exactly one birthDate"), and disjointness declarations ("nothing is both a Vehicle and a Building").
These axioms transform taxonomies into logical frameworks. Reasoners validate instance data against axioms, flagging violations and inferring implicit classifications.
Create individuals representing specific entities. For testing and validation, generate representative instances spanning your class hierarchy.
Production deployments often populate ontologies from databases, APIs, or data integration pipelines. But during development, manually crafted instances facilitate testing and expose modelling gaps.
Leverage automated reasoning to check consistency and infer implicit knowledge. Protégé integrates reasoners (ELK, HermiT, FaCT++) directly. Execute reasoning after significant changes to detect:
Inconsistencies: Contradictory assertions violating axioms. If you've declared classes disjoint but classified an individual under both, reasoners flag this immediately.
Unsatisfiable classes: Classes whose restrictions are logically impossible to fulfil. These indicate modelling errors requiring correction.
Inferred classifications: Individuals automatically classified based on their properties and relationships. If an individual supervises employees, reasoners may infer 'Manager' classification without explicit assertion.
Ontologies evolve; they're never truly "finished". New competency questions emerge. Domain understanding deepens. Integration requirements change.
Effective iteration requires:
Plan for evolution from the outset. Ontology architecture should accommodate extension without fundamental restructuring—modular design, clear extension points, and comprehensive documentation facilitate graceful evolution.
This workflow implies orderly progression, but reality involves backtracking, dead ends, and reconceptualisation. Each domain ontology development involves revising class hierarchies multiple times, restructuring property definitions, and completely redesigning patterns (such as the n-ary causal relations) before reaching a stable architecture.
Accept this messiness as inherent to knowledge formalisation. Ontology engineering explicates domain knowledge, forcing confrontation with ambiguities, inconsistencies, and gaps that informal understanding glosses over. The discomfort of this confrontation is the process working as intended—producing precise, rigorous knowledge representation from informal expertise.