Foundations and modelling judgement

A discipline for reasons, not a machine for answers

A source form can tell us that someone entered “seller”. A database can tell us that a key has remained unchanged. Neither establishes what the person is, what makes the role contextual, or which changes the identified thing can survive. Those are modelling judgements: claims about the intended world, supported by definitions, examples and the people responsible for that meaning.

The selected OPDA method uses UFO-informed distinctions and OntoClean analysis. UFO supplies an analytical vocabulary for such distinctions as kinds, roles, qualities and material relators. OntoClean supplies metaproperty questions that expose problematic classifications and inheritance. They contribute related but different ideas; neither is just another name for an RDF syntax or a validation engine.

Apply the discipline across the eight retained modelling concerns, not only a small “relator spine”. First understand the proposed referent. Then examine all four relevant axes, explain the classifications, and test their consequences under the adopted rules.

Identity: what counts as the same individual?

Identity concerns individuation: distinguishing one thing from another and recognising it across descriptions or changes. A kind supplies the relevant identity criterion; a subkind retains that criterion. An identifier is a device for referring to something under a convention. It can be excellent evidence without being the criterion itself.

In our fictional Harbour Court case, one building contains Flat 1 and Flat 2. A report and a title record both mention the building’s address. Equating the building with either document would confuse the described subject with a description. An address match helps locate related material; it does not make those resources one individual.

For a candidate dwelling definition, ask what happens if Flat 1 is subdivided. Does it cease, persist as one successor, or persist under a different domain convention? Record the alternatives and the evidence needed to choose. We leave that case unresolved here. A new code, a continued address or an old source model’s answer cannot settle the new definition by themselves.

ODR-0061’s identity check examines declared identity-supplying kinds and their asserted ancestors. A kind beneath two distinct identity-supplying kinds raises a conflict that the modeller must explain. The tool can find the incompatible declarations; it cannot establish the identity criterion from matching labels or decide that the contexts should be merged.

Rigidity: could membership cease while the bearer remains?

A rigid classification is essential to each of its instances. An anti-rigid classification is not essential to any of its instances: every bearer could cease to belong while remaining that individual. This concerns what could be the case, not simply what the records happen to show. A lifetime of recorded selling does not make Seller an essential kind.

Imagine that Maya sells Flat 1 while buying elsewhere. The two participations are compatible because each has its own context. If the sale ends, Maya need not cease to exist. That is a reason to analyse Seller as a role, with relational dependence, rather than as an identity-supplying kind.

Now reverse a tempting hierarchy. Suppose a modeller places a rigid Person class beneath an anti-rigid Seller class, because the source’s “seller” section contains all person records. The hierarchy says every person instance is classified as a seller, contradicting the declared essential-membership commitments. ODR-0061 requires this check along indirect as well as immediate subclass paths.

The direction matters. “An anti-rigid type must not subsume a rigid type” is not the universal claim “a role can never be a subclass of a kind”. OPDA separately chooses local roleOf and phaseOf annotations for those class-level relationships. The roles and change chapter distinguishes that encoding policy from the analytical rule.

Dependence: what must exist for this thing to exist?

A database foreign key says how records connect. Existential dependence asks something stronger about the modelled entities. If a proposed quality is the condition of a particular wall, it needs a bearer: the wall whose condition it is. A condition value such as “poor” is not itself that particular quality. A report recording the assessment is different again.

In ODR-0061’s intended contract, a mode or quality identifies a bearer through opda:inheresIn. A material relator identifies its bearers through opda:mediates. These are proposed local model predicates with implementation pending, not evidence that current candidate data already emits them.

The adopted relator check requires at least one own attribute and mediation of at least two bearers. Those are necessary declared conditions in this profile, not sufficient philosophical proof. Inventing an attribute merely to satisfy the count would defeat the analysis. The choice must earn its place through the domain evidence.

Unity: what makes these parts one whole?

Identity asks whether this is the same individual; unity asks what binds its parts into a whole. A list of records has membership, but its database grouping does not establish the unity of what the records describe. Equally, a building’s address does not explain which material parts constitute that building.

Consider a proposed functional whole in the Harbour Court example. Reviewers may use the organisation of parts and their contribution to a function to justify a functional-complex classification. A separately modelled amount of construction material raises a different question: dividing an amount is not the same operation as distinguishing the parts of the functioning whole. Do not express “made from” as “is a subclass of”.

The local controlled unity vocabulary has four choices: functional complex, collective, amount of matter and no unity. Functional complexes and collectives carry positive unity; amounts of matter carry anti-unity. “No unity” is its own value, not an alias for positive unity or missing information. The modeller must justify which classification applies.

ODR-0061 checks that an anti-unity class does not subsume a positive-unity class along the asserted hierarchy. A software aggregate boundary or a part/whole link may supply useful evidence, but neither is automatic proof of a unity criterion. The mechanical check only becomes meaningful when that classification is populated and defensible.