How a model goes wrong.

Making an entity a subclass of its own attribute

A policy runs for a period, so it is tempting to make it a kind of time interval. But a policy is an information entity that has a term; it is not itself an interval. The same slip turns a claim into a money amount, or a party into an address.

The tell: a subclass axiom where the parent is a property of the child — time, money, location, a code — not a genuine super-type.

policy:Policy rdfs:subClassOf time:DateTimeInterval .   # a policy IS an interval? no.

# The fix: the policy HAS a term; the term is the interval.
policy:Policy   rdfs:subClassOf core:InformationEntity .
agr:hasTerm     a owl:FunctionalProperty ;
                rdfs:domain agr:Agreement ; rdfs:range agr:AgreementTerm .
agr:AgreementTerm rdfs:subClassOf time:DateTimeInterval .   # the *term* is the interval

Using subclass for composition

A coverage belongs to a policy, so it gets filed under it with rdfs:subClassOf. But subsumption means “every coverage is a policy,” which is false. The relationship is mereological — a coverage is a part of a policy.

The test: read the axiom aloud as “every X is a Y.” If that is false but “X is a component of Y” is true, you want a part-of property, not a subclass.

coverage:Coverage rdfs:subClassOf policy:Policy .   # a coverage is not a kind of policy

# The fix: relate the whole to its part.
policy:hasCoverage a owl:ObjectProperty ;
        rdfs:domain policy:Policy ; rdfs:range coverage:Coverage ;
        rdfs:subPropertyOf core:hasPart .

Modeling a controlled value as a class

Perils, claim statuses, currencies and lines of business feel like classes, so each code becomes an owl:Class. A few hundred trivial subclasses later, the reasoner is classifying a code list and the business cannot add a value without a modeling change. These are values, not types.

The tell: a broad, flat subclass tree whose leaves are never instantiated — they only ever label something.

peril:Flood rdfs:subClassOf peril:Peril .   # hundreds of value-classes in the T-Box

# The fix: a SKOS concept in a scheme — governed data, referenced by the model.
peril:Flood a skos:Concept ; skos:inScheme peril: ;
        skos:prefLabel "Flood"@en ; skos:notation "FLD" .

Making a role a rigid subclass of the player

An underwriter is a person, so Underwriter ⊑ Person. But underwriter is a role a party plays, not a rigid kind it always is: the same person may also be a claimant, and may stop underwriting tomorrow. Baking the role into the class makes membership permanent and multiplies a person across every hat they wear. (This is the anti-rigidity pitfall from OntoClean.)

The tell: a subclass of Person or Organization named after a job, a relationship or a temporary state.

policy:Underwriter rdfs:subClassOf core:Person .   # once a person, forever an underwriter?

# The fix: reify the role; the person fills it via hasRole.
policy:UnderwriterRole a agr:PartyRole ; core:roleProperty policy:underwriter .
policy:Underwriter owl:equivalentClass
        [ owl:onProperty core:hasRole ; owl:hasValue policy:UnderwriterRole ] .

Using OWL as a validator

You want “every policy must have a policy number, or reject it,” so you write a minCardinality 1 restriction — and nothing gets rejected. Under the open-world assumption, a missing value is unknown, not absent: OWL infers the number exists somewhere, it does not flag its absence.

Assuming two different IRIs are two different things

OWL makes no unique-name assumption: ex:PartyA and ex:PartyB are not known to be distinct unless you say so. This surprises people through functional properties — asserting two values does not raise an error; it makes the two values owl:sameAs each other.

The tell: a functional property that “should have caught” a double-assignment but silently merged two individuals instead.

# hasPrimaryInsured is functional; two claimants are asserted…
ex:Claim-1 claim:hasClaimant ex:PartyA , ex:PartyB .
# …OWL does NOT complain — it infers ex:PartyA owl:sameAs ex:PartyB .

# The fix: assert distinctness (or class disjointness) so the clash is real.
[] a owl:AllDifferent ; owl:distinctMembers ( ex:PartyA ex:PartyB ) .

Writing restrictions that say nothing

A restriction can be syntactically valid and logically vacuous. minCardinality 0 is always true. someValuesFrom owl:Thing only says “has at least one of something.” They look like constraints and constrain nothing — noise a reviewer must decode and a reasoner must carry.

[ a owl:Restriction ; owl:onProperty policy:hasCoverage ; owl:minCardinality 0 ]   # always true
[ a owl:Restriction ; owl:onProperty policy:hasCoverage ; owl:someValuesFrom owl:Thing ] # ≥1 anything

# The fix: state the constraint you actually mean, or delete it.
[ a owl:Restriction ; owl:onProperty policy:hasCoverage ; owl:someValuesFrom coverage:Coverage ]

Reading allValuesFrom as “must have one”

allValuesFrom (∀) constrains only the values that are present; it does not require any to exist. A claim with zero losses satisfies “all losses are of type Loss” perfectly. If you meant “a claim has a loss,” you needed someValuesFrom (∃) or a qualified minimum.

claim:Claim rdfs:subClassOf [ owl:onProperty claim:hasLoss ; owl:allValuesFrom claim:Loss ] .
# satisfied by a claim with NO loss at all — probably not what you meant

# The fix: require existence.
claim:Claim rdfs:subClassOf [ owl:onProperty claim:hasLoss ; owl:someValuesFrom claim:Loss ] .

Putting cardinality on a non-simple property

Cardinality, functional and several other axioms are only legal in OWL 2 DL on simple properties — ones with no transitive sub-property. Hang a count on core:hasPart (transitive) and the ontology silently leaves the DL profile, so the reasoner you validate with may refuse it or fall back to a weaker logic.

The tell: a cardinality or FunctionalProperty axiom on a property that is, or has, a transitive sub-property.

core:hasPart a owl:TransitiveProperty , owl:FunctionalProperty .  # illegal in OWL 2 DL

# The fix: keep counts on a simple property designed for it.
agr:hasTerm a owl:FunctionalProperty ; rdfs:range agr:AgreementTerm .  # simple by design

Treating rdfs:domain / rdfs:range as constraints

Domain and range are not checks — they are inference rules. Declaring rdfs:domain policy:Policy does not forbid using the property elsewhere; it concludes that whatever you used it on is a policy. Point it at a claim, and if Policy and Claim are disjoint you have not caught an error — you have made the ontology inconsistent.

Sibling classes with no disjointness

Without owl:disjointWith, nothing stops an individual from being both a Person and an Organization, or a claim event from being an opening and a closing. Because OWL never assumes classes are separate, the contradiction you are counting on to catch a bug is never derived. Disjointness is what gives a reasoner something to falsify.

# Without this, Person ⊓ Organization is perfectly consistent — and bugs hide.
[] a owl:AllDisjointClasses ;
   owl:members ( core:Person core:Organization ) .

A typo mints a brand-new term

Write core:partipatesIn instead of core:participatesIn and nothing complains. In an open world, an unrecognised IRI is not a mistake — it is simply a new property with no domain, range or inverse. The triple is valid; no inference fires; the real property’s axioms never touch your data. The error is invisible to the reasoner and shows up only as a competency question that quietly returns nothing.

The tell: a query that should return rows returns none, and the culprit term appears exactly once in the whole graph.

ex:Claim-1 core:partipatesIn ex:PartyA .   # typo — a new, meaningless property
# the intended core:participatesIn, with its inverse and axioms, never applies