UFO, OntoUML and gUFO: The Foundational Ontology Conceptual Modelling Uses
BFO won government procurement. UFO won conceptual modelling. If you read defence and intelligence specifications you will see BFO and the Common Core Ontologies. If you read the conceptual modelling literature, or look at what people actually draw when they model a domain properly, you will see UFO and its modelling language OntoUML. The previous lesson compared the upper ontologies you are most likely to be asked about. This one covers the family that most repays study if your job is getting a domain model right, and the OWL artifact that lets you use it on the Semantic Web.

Three things with similar names
Keep them apart or the literature will not make sense. UFO, the Unified Foundational Ontology, is the theory, developed by Giancarlo Guizzardi and the NEMO group at the Federal University of Espirito Santo. It is layered: UFO-A covers endurants, the things that persist; UFO-B covers events; UFO-C covers social and intentional entities. OntoUML is the modelling language, a UML profile whose stereotypes are the UFO distinctions, which is what practitioners draw in. gUFO, gentle UFO, is the lightweight OWL 2 DL implementation for knowledge graphs, published at purl.org/nemo/gufo under CC BY 4.0. It implements a subset of UFO-A and UFO-B, and it is the one you import into Protege. The reference paper is Almeida, Guizzardi, Sales and Fonseca, “gUFO: A Gentle Foundational Ontology for Semantic Web Knowledge Graphs”, arXiv 2603.20948, March 2026.
Identity and rigidity, made operational
Two lessons ago you met OntoClean and its meta-properties. UFO’s contribution is to turn those philosophical tests into a vocabulary you can actually build with, and gUFO makes each one an OWL class you can assert.
A sortal is a type that supplies an identity criterion: it tells you what counts as the same one over time. gufo:Kind is the rigid sortal, the type an individual cannot stop instantiating without ceasing to exist. Person is a Kind. gufo:SubKind specialises a Kind rigidly. gufo:Phase is anti-rigid and holds because of an intrinsic condition, so Child and Adult are Phases of Person. gufo:Role is anti-rigid and holds because of a relational condition, so Student, Employee and Patient are Roles, not Kinds.
That single distinction prevents the most common modelling error in the field. Making Student a subclass of Person, with the same modelling status as Person itself, quietly asserts that a graduate is a different entity from the person who graduated. Model Student as a gufo:Role and the identity stays with the person, where it belongs.
Types that do not supply identity are non-sortals: gufo:Category is rigid and spans several Kinds, such as PhysicalObject; gufo:RoleMixin and gufo:PhaseMixin are the anti-rigid equivalents, such as Customer when a customer may be a person or an organisation; gufo:Mixin is semi-rigid.
Aspects: qualities, relators and situations
UFO does not stop at types. Properties are aspects that existentially depend on their bearer. A gufo:Quality, such as a weight or a colour, connects to its bearer with gufo:inheresIn. A gufo:Relator is the reified thing that makes a relationship true, connected to the entities it relates by gufo:mediates: an employment, a marriage, an insurance policy. The next lesson takes relators seriously, because they are the answer to a question most ontologies cannot even ask.
gUFO also ships situations, which are how you say that something held at a time without leaving the OWL 2 DL profile: gufo:TemporaryInstantiationSituation, gufo:TemporaryParthoodSituation, gufo:TemporaryRelationshipSituation and their siblings. This is UFO’s answer to the temporal problem that the 4D ontologies solve by a completely different route, which is the subject of the lesson after next.
Worked example · the Aberdeen-2 asset register
Where we left it: the register has two candidate metaphysical homes, BFO and 4D, with selection criteria written down; the type-level questions, roles and the HX-300 model, are still open.
gUFO is the third opinion, and it speaks directly to those open questions. Type the register’s core in it:
ex:Pump rdf:type gufo:Kind ;
rdfs:subClassOf gufo:FunctionalComplex .
ex:StandbyPump rdf:type gufo:Role ;
rdfs:subClassOf ex:Pump .
ex:P101 rdf:type ex:Pump .
ex:MaintenanceAgreement rdf:type gufo:Kind ;
rdfs:subClassOf gufo:Relator .
ex:Contract42 rdf:type ex:MaintenanceAgreement ;
gufo:mediates ex:OperatorCo , ex:ServiceCo .
Three earlier loose ends land at once. ex:P101 is an instance of the Kind ex:Pump, itself a gufo:FunctionalComplex: an object whose parts, the impeller among them, play functional roles within the whole, which is exactly the part-whole story the impeller swap needs. ex:StandbyPump becomes a gufo:Role, which formalises lesson 22’s OntoClean fix rather than merely restating it: anti-rigid, and held in virtue of a relational condition, the duty roster that stands P-101 behind the running unit. And ex:Contract42, which lesson 6’s mis-scoped domain axiom once silently classified as Equipment, finally receives its principled type: it is not equipment at all but a gufo:Relator, the reified truthmaker of the operator-contractor relationship, existentially dependent on both parties it mediates. The register can now answer “in virtue of what is ServiceCo our maintenance contractor?” with an entity, not a bare edge.
State of the register: core types carry gUFO stereotypes, StandbyPump is a Role, Contract42 is a Relator with its mediated parties; HX-300, the pump model, still has no principled home, and the next lesson gives it one.
| Question | UFO and gUFO | BFO | DOLCE |
|---|---|---|---|
| Primary community | Conceptual modelling, enterprise and information systems | Life sciences, defence and intelligence | Cognitive science, linguistics, academic work |
| Formal status | OWL 2 DL implementation, CC BY 4.0, no ISO status | ISO/IEC 21838-2:2021 | No ISO status. Several OWL renderings |
| Strength | The richest treatment of types: identity, rigidity, roles, relators, higher-order types | Institutional adoption and a large aligned ontology ecosystem | Philosophical depth on qualities and cognition |
| Modelling language | OntoUML, a UML profile, with tool support | No dedicated diagrammatic language | No dedicated diagrammatic language |
| Time and change | Endurant based, with situations for temporary facts | Continuants and occurrents | Endurant and perdurant distinction |
What breaks · Customer and Supplier as rigid subclasses
The register’s commercial slice needs to say who buys from whom. The ERP has a customer master and a supplier master, so the obvious move is to mirror them as subclasses of Organisation, and since a company is either one or the other in any given ledger, declare them disjoint:
ex:Customer rdfs:subClassOf ex:Organisation ;
owl:disjointWith ex:Supplier .
ex:Supplier rdfs:subClassOf ex:Organisation .
# ServiceCo maintains our pumps under ex:Contract42,
# and buys platform telemetry from us under ex:Contract57
ex:ServiceCo rdf:type ex:Supplier , ex:Customer .
The reasoner reports an inconsistent ontology: ex:ServiceCo instantiates two disjoint classes. Drop the disjointness and the model is merely wrong instead of broken: Customer and Supplier read as rigid, so when Contract57 lapses the triples claim ServiceCo still is a customer, essentially and forever, and there is no way to ask “customer to whom?”. The facts are relational, one organisation standing in two different relationships to two different counterparties, and rigid subclassing cannot say so.
Relators dissolve the contradiction rather than patching it. Type ex:Customer and ex:Supplier as gufo:RoleMixin (anti-rigid, and cross-cutting Kinds, since a customer may be a person or an organisation), and let each instantiation hold in virtue of a mediating relator: ServiceCo plays Supplier in virtue of ex:Contract42, Customer in virtue of ex:Contract57. Both at once, no clash, and each role ends exactly when its relator does.
Is it the most complete?
You will hear UFO described as the most complete upper ontology. Be precise about the claim. On the analysis of types and of what makes a relationship hold, UFO is unquestionably the most articulated of the mainstream options, and nothing in BFO or DOLCE matches its treatment of rigidity, sortality and relators. On institutional adoption it is behind: BFO is the one written into standards and government baselines, which is what you will be asked for in a procurement. Those are different kinds of completeness, and the professional answer is to know both and to pick on the basis of who has to accept your model.
Practically, gUFO is easy to try. Import it into Protege, assert your Kinds and Roles, and you inherit a set of distinctions that will expose muddled thinking in your own model within an hour. The next lesson pushes past the IsA and HasA skeleton that most published ontologies never escape.

Check yourself
You are assigning gUFO stereotypes to register terms. Which one of the following assignments is correct?
- ex:Pump is a gufo:Kind: it supplies the identity criterion that makes P-101 the same pump across exports, repairs and renames.
- ex:StandbyPump is a gufo:Phase, since standing by is a temporary condition the pump moves in and out of.
- ex:Equipment is a gufo:Kind, because every item in the register is equipment for its whole registered life.
- ex:Contract42 is a gufo:Role, played by ServiceCo for as long as the maintenance agreement runs.
Show the answer, and why each wrong option is wrong
A is correct. A Kind is the rigid sortal that supplies identity. Being a pump is what P-101 cannot stop being while remaining P-101, and the pump identity criterion (roughly, same functional unit through part replacement) is exactly what the register has leant on since the impeller swap.
B encodes the phase-for-role confusion. Temporariness alone does not make a Phase; the test is what the condition depends on. A Phase holds in virtue of an intrinsic condition (a CorrodedPump is corroded whatever else exists). Standby status holds in virtue of something outside the pump: the duty roster that stands it behind the running unit. Relational condition means gufo:Role, which is why lesson 22’s fix survives here unchanged.
C mistakes rigidity for sortality. Equipment is rigid, but it spans pumps, valves and pipelines, which carry different identity criteria, so it supplies none of its own. It is a gufo:Category, a rigid non-sortal. Typing it as a Kind would also leave P-101 instantiating two Kinds, Pump and Equipment, and an individual gets its identity from exactly one.
D confuses an individual with a type, and a relator with a role. ex:Contract42 is a particular agreement, an instance, so it cannot be a stereotype-bearing class at all; and the thing it is an instance of is a relator kind, not a role. ServiceCo plays the role MaintenanceContractor; Contract42 is the mediating entity in virtue of which it does. Collapse the two and the question “which contract makes this true?” loses its answer.
Further reading
- gUFO: the gentle Unified Foundational Ontology. Specification, vocabulary and examples. OWL 2 DL, CC BY 4.0. https://nemo-ufes.github.io/gufo/
- Almeida, J.P.A., Guizzardi, G., Sales, T.P. and Fonseca, C.M. gUFO: A Gentle Foundational Ontology for Semantic Web Knowledge Graphs. arXiv:2603.20948. https://arxiv.org/abs/2603.20948
- The OntoUML model catalogue: a public, FAIR collection of ontology-driven conceptual models to learn the patterns from. https://github.com/OntoUML/ontouml-models
