Mngr: Created page with "= Costasano Heritage Database – Conceptual Model (Version 5.0) = This document defines the '''conceptual architecture''' of the Costasano Heritage Database. It is the authoritative reference for: * meaning * responsibilities * boundaries * relationships It must be consulted '''before''' any logical or technical implementation. This version supersedes the v4 conceptual overview and incorporates all conceptual developments reflected in the DBML v5 schema. == Purp..."

2026-03-19T18:32:48Z

Created page with "= Costasano Heritage Database – Conceptual Model (Version 5.0) = This document defines the '''conceptual architecture''' of the Costasano Heritage Database. It is the authoritative reference for: * meaning * responsibilities * boundaries * relationships It must be consulted '''before''' any logical or technical implementation. This version supersedes the v4 conceptual overview and incorporates all conceptual developments reflected in the DBML v5 schema. == Purp..."

New page

= Costasano Heritage Database – Conceptual Model (Version 5.0) =

This document defines the '''conceptual architecture''' of the Costasano Heritage Database.
It is the authoritative reference for:

* meaning
* responsibilities
* boundaries
* relationships

It must be consulted '''before''' any logical or technical implementation.

This version supersedes the v4 conceptual overview and incorporates all conceptual developments reflected in the DBML v5 schema.

== Purpose ==

The conceptual model defines '''what the system represents''', independent of:

* database technology
* MediaWiki / Cargo
* Drupal file storage
* UI implementation

Its goal is to ensure:

* semantic clarity
* long‑term maintainability
* successor‑friendly understanding
* clean separation of responsibilities

No implementation detail may override or redefine the conceptual meaning described here.

== Core Architectural Principles ==

The model is built on five enduring principles.

=== 1. Separation of Concerns ===
Each entity has '''one responsibility'''.

No entity may take over the meaning of another.

=== 2. Conceptual First ===
Meaning is defined '''before''' implementation.

If meaning is unclear, implementation must wait.

=== 3. Stable Identifiers ===
Identifiers are:

* mechanical
* uniform
* non‑semantic

They must never encode interpretation.

=== 4. Minimal Semantics in Structure ===
Interpretation belongs in:

* descriptions
* notes
* citations

Not in:

* flags
* overloaded types
* ambiguous fields

=== 5. Technology Independence ===
The conceptual model must remain valid even if:

* Cargo is replaced
* MediaWiki is replaced
* Drupal is replaced
* storage changes

Only the logical schema depends on technology.

== Conceptual Architecture ==

The system models '''five conceptual layers''', each with a single responsibility.

{| class="wikitable"
! Layer !! Responsibility !! Conceptual Entities
|-
| Storage || physical digital files || File
|-
| Interpretation || scholarly representation of files || Asset
|-
| Research Subjects || historical actors and objects || Object, Person, Organisation
|-
| Spatial Context || where things exist or occur || Place
|-
| Narrative Structure || interpretation and storytelling || Chapter
|}

The conceptual flow is:

'''File → Asset → Research Entities → Place → Chapter'''

Each layer enriches the previous one without replacing it.

= Entity Definitions (Conceptual Layer) =

This section defines the meaning of each conceptual entity.
It is the '''authoritative semantic reference'''.

== 1. Storage Layer ==

=== File ===
Represents a '''physical digital file''' stored in Drupal.

* Files contain data, not meaning.
* Files may be replaced or reprocessed without altering interpretation.
* Files are not heritage entities.
* Files are referenced by Assets but do not interpret themselves.

Examples:

* a JPEG scan
* a TIFF archival reproduction
* a PDF document
* an audio recording

Files have '''no conceptual relationships''' to Objects, Persons, Places, or Chapters.

== 2. Interpretation Layer ==

=== Asset ===
Represents the '''scholarly interpretation''' of one or more Files.

An Asset is:

* a human‑interpreted representation
* a curated description of a file
* a contextualized heritage source

Assets may:

* describe, depict, or relate to Objects
* depict or originate from Places
* be created or held by Organisations
* relate to Persons
* belong to narrative Chapters

==== Asset Hierarchy ====
Assets may form a '''parent–child structure'''.

Examples:

* a multi‑page document
* a photo series
* a grouped set of scans

==== Asset Classification ====
Two conceptual dimensions:

* '''AssetType''' — what kind of thing it is (image, map, document, audio)
* '''AssetSourceType''' — how it was obtained (scan, photograph, archive copy)

==== Asset Provenance ====
Assets may include:

* repository
* rights
* citation
* source reference

==== Asset Publication Workflow ====
Assets may be:

* publishable
* internal
* AI‑processed

These are workflow attributes, not semantic ones.

== 3. Research Subjects Layer ==

=== Object ===
Represents a '''heritage object''' in the broadest sense.

An Object may be:

* a building
* a room
* a document
* an artifact
* a ship
* a tool
* a historical item

==== Object Hierarchy ====
Objects form a '''tree'''.

Examples:

* Building → Room → Artifact
* Archive → Collection → Item

==== Object Temporal Span ====
Objects may have:

* DateFrom
* DateTo

These describe the period of existence or relevance.

==== Object Relationships ====
Objects may relate to:

* Assets (ObjectAsset)
* Persons (ObjectPerson)
* Organisations (ObjectOrganisation)
* Keywords (ObjectKeyword)
* Chapters (ObjectChapter)
* Holders (ObjectHolder)

==== Object Classification ====
Objects have:

* Type
* Subtype

These are descriptive, not prescriptive.
They do not encode logic.

=== Person ===
Represents a '''historical or contemporary individual'''.

Persons may:

* appear in Assets
* relate to Objects with a role
* belong to Organisations with a role

Persons have:

* biographical data
* notes
* contact information (if relevant)

=== Organisation ===
Represents an '''institution, company, group, or body'''.

Organisations may:

* appear in Assets
* relate to Objects with a role
* have members (PersonOrganisationRole)
* be located in a Place

Organisations are not Places; they merely occupy them.

== 4. Spatial Layer ==

=== Place ===
Represents a '''geographical or administrative location'''.

Examples:

* country
* region
* city
* street
* building
* room

==== Place Hierarchy ====
Places form a '''tree'''.

Example:

* Belgium → West Flanders → Ostend → Street → Building → Room

==== Geocoding ====
Places may have:

* latitude
* longitude

Coordinates describe the Place itself, not the Objects or Assets.

== 5. Narrative Layer ==

=== Chapter ===
Represents a '''narrative or interpretive segment'''.

Chapters structure:

* storytelling
* historical interpretation
* thematic grouping

==== Chapter Hierarchy ====
Chapters form a '''tree'''.

Example:

* 19th Century → Industrialisation → Local Shipyards

==== Temporal Span ====
Chapters may have:

* StartYear
* EndYear

These describe the narrative period, not the Object’s existence.

==== Object–Chapter Relationship ====
Objects may belong to multiple Chapters.

= Relationship Concepts =

The conceptual model uses several relationship patterns.

== 1. Intrinsic Relationships ==

These are stored directly on the entity because they are '''inherent properties'''.

Examples:

* Asset.Place
* Asset.Organisation
* Asset.Chapter
* Object.Place
* Organisation.Place

Intrinsic relationships describe '''what the entity is''', not how it is used.

== 2. Contextual Relationships (Junctions) ==

These describe '''interpretive or contextual links'''.

They are not inherent properties.

Examples:

* ObjectAsset
* PersonAsset
* OrganisationAsset
* ObjectPerson
* ObjectOrganisation
* ObjectKeyword
* PersonOrganisationRole
* ObjectHolder

These relationships may include:

* roles
* preferences
* contextual meaning

== 3. Role‑Based Relationships ==

Roles describe '''how one entity relates to another'''.

Examples:

* PersonRole
* OrganisationRole
* AssetRole

Roles are not types of entities; they are '''types of relationships'''.

= Hierarchies =

The conceptual model contains '''four independent hierarchies''':

* Object hierarchy
* Place hierarchy
* Chapter hierarchy
* Asset hierarchy

Each hierarchy has its own meaning and must not be conflated.

= Temporal Semantics =

The model distinguishes between:

* '''Object time''' — when an Object existed
* '''Narrative time''' — the period a Chapter describes

These are independent.

= Keywords =

Keywords provide '''thematic tagging''' of Objects.

They do not classify Assets, Persons, or Organisations.

= Holders =

ObjectHolder represents the '''current custodian''' of an Object.

A holder may be:

* a Person
* an Organisation

Only one of these should be used per record.

= Maintenance Workflow =

When extending the system:

# Update Entity Definitions (this document)
# Update the Conceptual Diagram
# Update the DBML schema
# Update Page Forms / Cargo tables
# Document architectural changes

= Status =

This is the '''authoritative conceptual model – Version 5.0'''.

All logical and technical implementations must conform to the definitions above.

ICT:Data Conceptual Model v 5.0 - new - Revision history