The taxonomy trap.

PIT-1 role vs type

The Role Trap — an office is not a kind of organization

Of the 107,042 nodes, 64% were not organizations at all. They were offices, hanging off the “governing body” node (Q895526): “Mayor of Berlin,” “Director-General of UNESCO,” “Commander of the Third Army Corps.” A governing body technically is an organizational construct, so the modeling is valid — but a role is a position an entity occupies, not an intrinsic kind. A city government does not become a different type of organization when its mayor changes.

The tell: labels with “of”/“for” + a proper noun (“Chancellor of Germany”), authority titles (Governor, Commander, Commissioner, Inspector), and whole subtrees rooted at Position, Office, Post or Appointment.

:MayorOfBerlin  rdfs:subClassOf  :Organization .   # an office is not an org type

# The fix: the organization CREATES a role; individuals OCCUPY it.
:Municipality   core:createsRole  :Mayor .
:Mayor          core:withinOrganization  :Municipality ;
                core:occupiedBy  ex:AngelaX .     # P31 to a person, not P279

PIT-2 dimension vs type

The Dimension Trap — why there aren’t 19,000 kinds of hospital

Remove the offices and 28,000 nodes remain — still too many, because of a subtler pathology. “Hospital” should have perhaps twenty structural subtypes. Instead it has German hospital, French hospital, Catholic hospital, public hospital, former hospital, hospital in France… Each base concept spawns a combinatorial product of country × scope × denomination × ownership × historical-state. Fifty countries, five scopes, ten denominations, two states = 5,000 variants of one concept.

A dimension is any property whose value varies independently of the fundamental type. The test: move a hospital from Germany to France — does its type change? No. Change its specialisation from pediatrics to oncology — does its type change? Yes. The first is a dimension (a property); the second approaches a real subclass determinant.

:GermanHospital  rdfs:subClassOf  :Hospital .
:CatholicHospital  rdfs:subClassOf  :Hospital .
:FormerHospital  rdfs:subClassOf  :Hospital .

# The fix: one class, the dimensions as properties on the instance.
ex:StMary  a :Hospital ;
    core:hasLocation       country:DE ;
    core:hasDenomination   denom:Catholic ;
    core:operatingStatus   status:Closed ; core:closureDate "1998" .

The folding rule — the intellectual crux. Not every qualifier is incidental; some are definitional. Before removing a variant, strip the qualifier and check whether a direct parent in the cleaned hierarchy already carries the stripped label. If yes, fold it up. If no, the qualifier may be definitional — keep the node for human review.

PIT-3 instance vs type

The Instance Trap — when a specific bank becomes a “type” of branch

Under bank branch sat 75 subclasses: “HDFC Bank branch,” “ICICI Bank branch,” “State Bank of India branch…” — each with hundreds of instances, because every physical HDFC branch had been tagged instance of: HDFC Bank branch. A named specific entity had been modeled as a type, usually a data-entry shortcut: it is easier to mint a class than to look up the parent bank for an operatedBy link.

Three tells: a proper-noun label (“HDFC Bank branch”), a leaf with 500+ instances and zero children, and the “[Named Entity] [generic type]” construction where the generic type already exists in the hierarchy.

:HDFCBankBranch  rdfs:subClassOf  :BankBranch .    # a proper noun as a class
ex:BranchA  a  :HDFCBankBranch .

# The fix: the branch is an instance of the generic type; the bank is a property.
ex:BranchA  a :BankBranch ; :operatedBy ex:HDFCBank .
ex:BranchB  a :BankBranch ; :operatedBy ex:HDFCBank .   # class :HDFCBankBranch deleted

PIT-4 one kind vs another

The Category Mistake — when a migration became an organization

Gilbert Ryle’s category mistake: treating something of one ontological kind as another. Entire subtrees under “organization” were events, phenomena or belief systems — “military campaign,” “human migration,” “diaspora,” “Buddhism,” “conspiracy theory.” They arrive through polyhierarchy: a “protest march” is both an event and an organized group action, and if that second parent links to “organization,” the march is dragged in — not by intent, but by the path of P279 edges.

The substitution test: read it as “a military campaign is a kind of organization.” An organization is persistent, with members and governance. A campaign is time-bounded, with participants and a command structure that exists only while it runs. It fails — not because the words feel wrong, but because the structural features that define “organization” are absent.

# At scale, automate the test with property signatures.
for C in hierarchy:
    inst = entities where P31 == C
    temporal = fraction(inst with start_date and end_date)
    spatial  = fraction(inst with coordinates)
    if temporal > 0.80:                       # classify C as EVENT_TYPE
    if spatial > 0.80 and temporal < 0.20:      # classify C as PLACE_TYPE

PIT-5 what it is vs what it does

The Industry Trap — Apple is not (only) a technology company

“Technology company,” “oil company,” “pharmaceutical company” are real, useful categories — but they classify organizations by business domain, not by structure. Apple is a technology company, a retail company, a media company and a financial-services company at once. Subclassing forces it into multiple, conflicting inheritance chains. That multiplicity is the sign the dimension is wrong.

• It can join or leave without changing form. A firm can exit cement and enter software — same legal entity, same governance.
• It is defined by what the org does, not what it is. “Corporation” is structural; “pharmaceutical company” is an activity.
• It overlaps with its siblings. Media and technology at once — a domain tag, not an exclusive category.

# Structure stays in OWL — logical commitments, inheritance.
biz:Corporation  a owl:Class ; rdfs:subClassOf biz:Company .

# Industry becomes a SKOS concept scheme — flexible domain tagging.
ind:Technology   a skos:Concept ; skos:inScheme ind:IndustryScheme .

# The instance is one structural type, tagged with many industries.
ex:Apple  a biz:Corporation ;
    biz:hasIndustry  ind:Technology , ind:Retail , ind:Media .

PIT-6 graph, not tree

The Diamond Trap — traverse fully, then subtract

Wikidata has multiple inheritance: “administrative territorial entity of Canada” is a child of both “administrative territorial entity” (which you want to exclude) and “Canadian organization” (which you want to keep). That diamond breaks the obvious algorithm. If you block descent whenever you enter an excluded subtree, the node still reaches your results through the other, non-excluded path — and you cannot tell during traversal whether you arrived “through” or “around” an excluded parent.

# WRONG — block during traversal
def bfs_with_blocking(root, excluded):
    while queue:
        n = queue.pop()
        if n in excluded: continue   # the other path still delivers n
        visited.add(n); queue.extend(children[n])

# RIGHT — traverse everything, then subtract the closures
def bfs_full_then_subtract(root, excluded_roots):
    all_nodes = full_bfs(root)                       # ignore exclusions
    excluded  = union(expand_subtree(r) for r in excluded_roots)
    return all_nodes - excluded                       # identity, not path

The lesson: inclusion in an excluded set is a property of the node, not of the traversal path. We found this empirically — Q3750285 survived the naive blocker because a non-geographic parent still reached it.

PIT-7 keeping everything

The Threshold Illusion — the danger of keeping everything

Even at 28,000 nodes, the tree is too large to review or maintain. A simple proxy sorts genuine types from noise: count how many real entities claim to be of that type. Leaf nodes with fewer than ~50 instances are, in practice, almost never genuine structural types — they are named entities misfiled as classes, or concepts too narrow to add information (“Briquette Factory” tells you little more than “manufacturing facility”).

Fifty is not magic — it is a proxy for “has the world provided enough evidence, in typed entities, that this concept deserves a named class?” And the pruning must run iteratively to a fixed point: removing a leaf can orphan its parent, whose count may now be below threshold too. In this cleanup, nine iterations were needed, and ~40% of all removals happened in rounds 2 through 9. A single pass would have left thousands of empty intermediate nodes organizing nothing.