Person, Organisation and HeritageObject – Modelling Rules

Purpose

This page explains the conceptual difference between:

Person
Organisation
HeritageObject

These three entities represent fundamentally different types of things.

Clearly separating them is essential to keep the data model consistent and avoid confusion.

Core principle

When entering data, always ask:

Is this a person, a group of people, or a physical thing?

The answer determines which entity must be used.

Definitions

Person

A single individual human being.

Examples:

architect
priest
sister
mayor
soldier
photographer
witness
owner

Typical attributes:

birth date
death date
biography
roles
nationality

Rule:

Use Person ONLY for one individual.

Organisation

A group or collection of people acting together as one entity.

Examples:

Congregation of Sisters of Charity
hospital staff
parish council
Red Cross
heritage club
municipality
fire brigade
school board
religious order

These are:

not one person
not a physical object
but still actors

Typical attributes:

name
type (association, order, service, etc.)
founding date
mission/description

Rule:

Use Organisation for any collective or group of persons.

HeritageObject

A physical object, building, site or construction.

Examples:

church building
bunker
farmhouse
bridge
lighthouse
monument
cemetery
statue
ruin

These are things that:

exist physically
have a location
can be photographed
can be measured or restored

Typical attributes:

coordinates
construction date
materials
condition
protection status

Rule:

Use HeritageObject only for tangible, physical things.

Why this separation is important

Mixing these concepts causes serious modelling problems.

For example:

If a person were stored as a HeritageObject:

why would a person have coordinates?
why would a person have construction year?

If a building were stored as a Person:

why would it have a birth date?
why would it have a biography?

Such mixing leads to:

meaningless fields
inconsistent data
difficult queries
confusion for users

Therefore the three concepts must remain strictly separated.

Typical grey cases

Statue of a person

Not a person.

It is a physical object.

→ HeritageObject (type = statue)

Grave or tomb

Not a person.

It is a physical site.

→ HeritageObject (type = grave or monument)

Congregation of sisters

Not one individual.

It is a group.

→ Organisation

Hospital staff

Not a building, not one person.

→ Organisation

Architect who designed a church

Two separate entities:

Person: the architect
HeritageObject: the church

Relation:

church → designed by → person

Never merge them.

Relationships between entities

The model becomes powerful when relations are used:

Examples:

HeritageObject → designed by → Person
HeritageObject → owned by → Organisation
HeritageObject → operated by → Organisation
Organisation → located in → Place
Person → member of → Organisation

This allows rich historical descriptions while keeping entities clean.

Simple rule for club members

If unsure, remember:

Person = WHO
Organisation = GROUP OF WHO
HeritageObject = WHAT

This rule is usually sufficient to decide correctly.

Conclusion

Always use:

Person for individuals
Organisation for groups
HeritageObject for physical things

Never mix these categories.

This separation keeps:

the database clean
forms simple
queries reliable
and the system maintainable long term.