ICT:Architecture
System Architecture
This page describes the overall technical architecture of the MediaWiki installation used for heritage research and digital asset management.
It explains the roles of the main components and how they interact.
Architectural Goals
The architecture is designed to:
- Support complex, relational research data
- Scale to many objects, persons, and digital assets
- Separate internal research work from public presentation
- Minimize future refactoring
- Remain compatible with MediaWiki core and extensions
Layered Architecture
The system is structured in logical layers:
| Layer | Component | Responsibility |
|---|---|---|
| Presentation | Pages (Main namespace) | Public narratives and results |
| Structured Content | HO:, DA: namespaces | Internal structured entities |
| Data Entry | Forms (Page Schemas) | Controlled input |
| Schema Definition | Page Schemas | Mapping fields to storage |
| Data Storage | Cargo | Database schema and persistence |
| Physical Storage | File: namespace | Uploaded files |
Each layer has a single responsibility and must not take over the role of another layer.
Core Components
Cargo
Cargo is the authoritative data storage layer.
- Defines database tables
- Controls field types
- Executes schema changes
- Stores normalized data
Cargo tables are defined on wiki pages (`Cargo:…`) and must be manually activated by saving the page.
Forms
Forms provide:
- Editor-friendly data entry
- Controlled creation of pages
- Enforcement of required fields
- Repeatable sections for relationships
Forms are the only supported way to create structured pages.
Namespaces
Namespaces separate concerns and enable access control.
Namespaces are structural and long-lived decisions.
Files and the Digital Asset Abstraction
Digital Assets (DA) are metadata pages that represent conceptual media objects (files)
They abstract over:
- One or more files
- Derivatives
- OCR outputs
- Language versions
- Relationships to heritage objects
Files are never treated as data entities by themselves.
Architectural Constraints
The following constraints apply:
- No direct database schema manipulation
- No semantic meaning stored only on File: pages
- No public dependency on private files
- No uncontrolled page creation in structured namespaces
Status
This architecture is the baseline for all future development.