Mngr: Created page with "= HeritageObject Type – Concept and Purpose = == Why do we need a "Type" for HeritageObjects? == Each HeritageObject represents a physical or historical item such as: * church * bunker * farmhouse * bridge * lighthouse * monument * cemetery * windmill * etc. These objects must be '''classified''' in a consistent way. The field '''Type''' answers the simple question: ''"What kind of object is this?"'' == Why not simply use free text? == A simple text field like..."

2026-02-10T08:08:37Z

Created page with "= HeritageObject Type – Concept and Purpose = == Why do we need a "Type" for HeritageObjects? == Each HeritageObject represents a physical or historical item such as: * church * bunker * farmhouse * bridge * lighthouse * monument * cemetery * windmill * etc. These objects must be '''classified''' in a consistent way. The field '''Type''' answers the simple question: ''"What kind of object is this?"'' == Why not simply use free text? == A simple text field like..."

New page

= HeritageObject Type – Concept and Purpose =

== Why do we need a "Type" for HeritageObjects? ==

Each HeritageObject represents a physical or historical item such as:

* church
* bunker
* farmhouse
* bridge
* lighthouse
* monument
* cemetery
* windmill
* etc.

These objects must be '''classified''' in a consistent way.

The field '''Type''' answers the simple question:

''"What kind of object is this?"''

== Why not simply use free text? ==

A simple text field like:

type = church

looks easy but quickly creates problems.

Examples of inconsistent input:

* church
* Church
* chapel
* kerkje
* small church

This causes:

* spelling variations
* duplicate meanings
* impossible filtering
* unreliable statistics
* messy reports

Over time this becomes unmanageable.

== The chosen solution ==

Instead of free text, we use a separate table:

'''HeritageObjectType'''

Relationship:

HeritageObject → HeritageObjectType

So every object selects its type from a predefined list.

== Advantages of using a separate Type table ==

=== 1. Consistency ===
Users must select from an existing list.
No spelling errors or variations.

=== 2. Reliable filtering ===
Examples:

* show all bunkers
* show all churches
* count monuments per type

These queries become simple and accurate.

=== 3. Statistics and reporting ===
Cargo queries can group by type:

* number of churches
* number of bridges
* number of military objects

=== 4. Extensibility ===
The type table can later store extra metadata:

* description
* icon
* color
* category
* historical period
* translations

Without changing the HeritageObject table.

=== 5. Controlled vocabulary ===
The club agrees once on the official terminology.

== Data model principle ==

This follows a standard database design rule:

''Do not use free text for classification fields.''

Instead:

Entity → Category/Type table

Other examples in this project:

* Chapter hierarchy (parent chapter)
* DigitalAssets linked to Chapter/Place/Organisation
* HeritageObject linked to Type

This keeps the data clean and structured.

== How it is implemented in MediaWiki ==

* Namespace: HeritageObjectType
* One page per type
* Cargo table stores all types
* Form uses a dropdown/combobox:

values from namespace=HeritageObjectType

Users select a type instead of typing text.

== Practical explanation for club members ==

If asked:

''"What is Type for?"''

Answer simply:

''Type is the official category of the object (church, bunker, bridge, etc.) chosen from a list so everyone uses the same terminology.''

== Conclusion ==

The Type relation:

* improves data quality
* avoids ambiguity
* enables statistics
* supports future growth

It is therefore an essential part of the data model.

Reaserch:Typing relations - Revision history