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.

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.