ICT:Data Model Entity Definitions - v 3.2: Difference between revisions
Created page with "= Data Model – Entity Definitions = This page defines the principal conceptual entities used in the project’s data model. Its purpose is to establish a shared and explicit understanding of what each entity represents before any technical implementation is undertaken. These definitions describe meaning and responsibility, not database structure or software mechanics. == Scope == These definitions guide: * conceptual ER modeling * DBML and Cargo schemas * Page..." |
No edit summary |
||
| Line 142: | Line 142: | ||
* play roles within Organizations | * play roles within Organizations | ||
* act as a holder of HeritageObjects | * act as a holder of HeritageObjects | ||
* be documented by | * be documented by DigitalAssets (portraits, letters, biographies, articles) | ||
Roles belong to relationships, not to the Person entity itself. | |||
=== Purpose === | |||
Persons model historical agency, responsibility, and participation. | |||
== Organization == | |||
=== Definition === | |||
An '''Organization''' represents a historical collective actor with institutional continuity. | |||
It answers the question: | |||
''“Which collective body acted or was responsible?”'' | |||
=== Examples === | |||
* religious congregations | |||
* companies | |||
* associations | |||
* institutions | |||
* managing bodies | |||
=== What an Organization is not === | |||
An Organization is: | |||
* not a person | |||
* not a HeritageObject | |||
* not a MediaWiki user group | |||
=== Relationships === | |||
An Organization may: | |||
* play roles in relation to HeritageObjects | |||
* include Persons with roles | |||
* act as holder of HeritageObjects | |||
* be documented by DigitalAssets (reports, articles, archival material) | |||
=== Purpose === | |||
Organizations model collective responsibility and institutional continuity. | |||
= Digital Representation and Sources = | |||
== DigitalAsset (DA) == | |||
=== Definition === | |||
A '''DigitalAsset (DA)''' represents the research interpretation and extended metadata of '''exactly one''' digital file. | |||
It answers the question: | |||
''“How do we interpret and describe this specific digital file as a research source?”'' | |||
A DigitalAsset is the human, scholarly layer that gives meaning to a file. | |||
=== Core principle === | |||
'''One DigitalAsset corresponds to exactly one File.''' | |||
There is never a grouping of multiple files inside one DigitalAsset. | |||
Each file that requires interpretation has its own DigitalAsset. | |||
=== Examples === | |||
A DigitalAsset may represent: | |||
* a photograph | |||
* a scanned document | |||
* an OCR transcription | |||
* a cropped derivative | |||
* a newspaper article | |||
* a portrait | |||
* a letter or archival record | |||
=== Relationship to Files === | |||
A DigitalAsset: | |||
* always references exactly one File | |||
* does not manage storage | |||
* does not replace MediaWiki file handling | |||
Files are storage. | |||
DigitalAssets are interpretation. | |||
=== Recursive behavior === | |||
DigitalAssets are '''recursive'''. | |||
A DigitalAsset may: | |||
* derive from another DigitalAsset | |||
* have multiple derived children | |||
This models provenance and processing chains. | |||
=== Relationship to research entities === | |||
A DigitalAsset may document one or more: | |||
* HeritageObjects | |||
* Persons | |||
* Organizations | |||
DigitalAssets therefore function as research sources. | |||
=== Publication and citation role === | |||
DigitalAssets may additionally store: | |||
* bibliographic citation text | |||
* repository information | |||
* permalinks | |||
* rights information | |||
* publication suitability | |||
Public pages cite DigitalAssets as sources and may display their associated files as illustrations. | |||
=== What a DigitalAsset is not === | |||
A DigitalAsset is: | |||
* not a file | |||
* not a container of files | |||
* not a historical object itself | |||
* not merely technical metadata | |||
=== Purpose === | |||
DigitalAssets exist to: | |||
* separate meaning from storage | |||
* provide rich research metadata | |||
* document provenance | |||
* serve as scholarly sources | |||
* support referencing and citation | |||
== File (External System Entity) == | |||
=== Definition === | |||
A '''File''' is a physical digital object managed by MediaWiki. | |||
=== Modeling status === | |||
Files are: | |||
* external to the conceptual research domain | |||
* managed entirely by MediaWiki | |||
* included only as reference entities | |||
Files provide storage only. | |||
They gain research meaning only through DigitalAssets. | |||
= Research Structure = | |||
== ResearchChapter == | |||
=== Definition === | |||
A '''ResearchChapter''' represents a conceptual or narrative unit of interpretation. | |||
It answers the question: | |||
''“Where does this belong in the research story?”'' | |||
=== Characteristics === | |||
A ResearchChapter: | |||
* structures interpretation | |||
* is not merely a date range | |||
* may be thematic or chronological | |||
* may overlap with other chapters | |||
=== Structural behavior === | |||
ResearchChapters are '''recursive'''. | |||
Chapters may contain subchapters. | |||
Top levels often represent time slices. | |||
Lower levels often represent themes. | |||
=== Relationships === | |||
* a Chapter may include multiple HeritageObjects | |||
* a HeritageObject may belong to multiple Chapters | |||
=== Purpose === | |||
ResearchChapters organize interpretation rather than historical reality itself. | |||
= Supporting Concepts = | |||
== Keywords == | |||
Keywords provide flexible thematic tagging. | |||
They support discovery but do not define structure. | |||
== Roles == | |||
Roles qualify relationships between entities. | |||
Examples: | |||
* creator | |||
* owner | |||
* restorer | |||
* shareholder | |||
* board member | |||
* holder | |||
Roles belong to relationships, not to entities themselves. | |||
== Treatment of Uncertainty (Certainty) == | |||
=== Conceptual position === | |||
Uncertainty is inherent in historical research. | |||
Many statements involve approximation or interpretation. | |||
=== Design decision === | |||
The data model deliberately does NOT implement: | |||
* certainty entities | |||
* confidence scores | |||
* high/medium/low levels | |||
* probability flags | |||
Uncertainty is not stored structurally. | |||
=== Rationale === | |||
Formal certainty levels: | |||
* create false precision | |||
* oversimplify interpretation | |||
* increase editorial burden | |||
* convey less information than descriptive notes | |||
Descriptive explanation is preferred. | |||
=== How uncertainty is expressed === | |||
Use: | |||
* precise wording | |||
* ranges or approximate values | |||
* explicit notes | |||
* citations to DigitalAssets | |||
Example: | |||
"mentioned only once in a newspaper article" | |||
is preferred over | |||
"certainty = low". | |||
=== Future extension === | |||
Structured certainty may be added only if clear analytical needs arise. | |||
Until then, descriptive practice remains the standard. | |||
== Status == | |||
This document defines the agreed conceptual meaning of the entities – Version 3.2. | |||
All ER diagrams, DBML definitions, schemas, and implementations must conform to these definitions. | |||
Latest revision as of 15:46, 23 January 2026
Data Model – Entity Definitions
This page defines the principal conceptual entities used in the project’s data model.
Its purpose is to establish a shared and explicit understanding of what each entity represents before any technical implementation is undertaken.
These definitions describe meaning and responsibility, not database structure or software mechanics.
Scope
These definitions guide:
- conceptual ER modeling
- DBML and Cargo schemas
- Page Schemas and forms
- editorial workflows
- interpretation of diagrams and documentation
If an entity definition is unclear or disputed, implementation must be postponed.
Conceptual overview
The model separates clearly between:
- Storage → Files
- Interpretation of files / sources → DigitalAssets
- Subjects of research → HeritageObjects, Persons, Organizations
- Narrative structure → ResearchChapters
The fundamental conceptual flow is:
File → DigitalAsset → Research Entity
Files provide storage. DigitalAssets provide interpretation and source metadata. Research entities provide historical meaning.
This separation prevents semantic confusion and keeps responsibilities explicit.
Core Research Entities
HeritageObject (HO)
Definition
A HeritageObject (HO) represents a historical, conceptual, or material entity that is the subject of study.
It answers the question:
“What is the thing we are studying?”
Examples
A HeritageObject may represent:
- a sanatorium
- a building
- a document or register
- a historically meaningful place
- a room, component, or architectural element
- a conceptual or functional unit (e.g. “medical practice”)
What a HeritageObject is not
A HeritageObject is:
- not a digital file
- not a person
- not an organization
- not a research chapter
- not a technical database record
Structural behavior
HeritageObjects are recursive.
Each HeritageObject may:
- have zero or one parent HeritageObject
- have zero or more child HeritageObjects
This supports conceptual decomposition and hierarchical structuring.
Relationships
A HeritageObject may:
- be documented by multiple DigitalAssets
- designate one DigitalAsset as preferred representation
- be linked to Persons with roles
- be linked to Organizations with roles
- have Persons or Organizations as holders
- belong to multiple ResearchChapters
- be tagged with Keywords
Purpose
HeritageObjects are the primary conceptual anchors of the research.
Person
Definition
A Person represents a historical individual with agency.
It answers the question:
“Who was involved historically?”
Examples
- religious sisters
- directors
- architects
- patients
- shareholders
- board members
What a Person is not
A Person is:
- not a MediaWiki user account
- not a HeritageObject
- not an organization
Relationships
A Person may:
- play roles in relation to HeritageObjects
- play roles within Organizations
- act as a holder of HeritageObjects
- be documented by DigitalAssets (portraits, letters, biographies, articles)
Roles belong to relationships, not to the Person entity itself.
Purpose
Persons model historical agency, responsibility, and participation.
Organization
Definition
An Organization represents a historical collective actor with institutional continuity.
It answers the question:
“Which collective body acted or was responsible?”
Examples
- religious congregations
- companies
- associations
- institutions
- managing bodies
What an Organization is not
An Organization is:
- not a person
- not a HeritageObject
- not a MediaWiki user group
Relationships
An Organization may:
- play roles in relation to HeritageObjects
- include Persons with roles
- act as holder of HeritageObjects
- be documented by DigitalAssets (reports, articles, archival material)
Purpose
Organizations model collective responsibility and institutional continuity.
Digital Representation and Sources
DigitalAsset (DA)
Definition
A DigitalAsset (DA) represents the research interpretation and extended metadata of exactly one digital file.
It answers the question:
“How do we interpret and describe this specific digital file as a research source?”
A DigitalAsset is the human, scholarly layer that gives meaning to a file.
Core principle
One DigitalAsset corresponds to exactly one File.
There is never a grouping of multiple files inside one DigitalAsset.
Each file that requires interpretation has its own DigitalAsset.
Examples
A DigitalAsset may represent:
- a photograph
- a scanned document
- an OCR transcription
- a cropped derivative
- a newspaper article
- a portrait
- a letter or archival record
Relationship to Files
A DigitalAsset:
- always references exactly one File
- does not manage storage
- does not replace MediaWiki file handling
Files are storage. DigitalAssets are interpretation.
Recursive behavior
DigitalAssets are recursive.
A DigitalAsset may:
- derive from another DigitalAsset
- have multiple derived children
This models provenance and processing chains.
Relationship to research entities
A DigitalAsset may document one or more:
- HeritageObjects
- Persons
- Organizations
DigitalAssets therefore function as research sources.
Publication and citation role
DigitalAssets may additionally store:
- bibliographic citation text
- repository information
- permalinks
- rights information
- publication suitability
Public pages cite DigitalAssets as sources and may display their associated files as illustrations.
What a DigitalAsset is not
A DigitalAsset is:
- not a file
- not a container of files
- not a historical object itself
- not merely technical metadata
Purpose
DigitalAssets exist to:
- separate meaning from storage
- provide rich research metadata
- document provenance
- serve as scholarly sources
- support referencing and citation
File (External System Entity)
Definition
A File is a physical digital object managed by MediaWiki.
Modeling status
Files are:
- external to the conceptual research domain
- managed entirely by MediaWiki
- included only as reference entities
Files provide storage only. They gain research meaning only through DigitalAssets.
Research Structure
ResearchChapter
Definition
A ResearchChapter represents a conceptual or narrative unit of interpretation.
It answers the question:
“Where does this belong in the research story?”
Characteristics
A ResearchChapter:
- structures interpretation
- is not merely a date range
- may be thematic or chronological
- may overlap with other chapters
Structural behavior
ResearchChapters are recursive.
Chapters may contain subchapters.
Top levels often represent time slices. Lower levels often represent themes.
Relationships
- a Chapter may include multiple HeritageObjects
- a HeritageObject may belong to multiple Chapters
Purpose
ResearchChapters organize interpretation rather than historical reality itself.
Supporting Concepts
Keywords
Keywords provide flexible thematic tagging.
They support discovery but do not define structure.
Roles
Roles qualify relationships between entities.
Examples:
- creator
- owner
- restorer
- shareholder
- board member
- holder
Roles belong to relationships, not to entities themselves.
Treatment of Uncertainty (Certainty)
Conceptual position
Uncertainty is inherent in historical research.
Many statements involve approximation or interpretation.
Design decision
The data model deliberately does NOT implement:
- certainty entities
- confidence scores
- high/medium/low levels
- probability flags
Uncertainty is not stored structurally.
Rationale
Formal certainty levels:
- create false precision
- oversimplify interpretation
- increase editorial burden
- convey less information than descriptive notes
Descriptive explanation is preferred.
How uncertainty is expressed
Use:
- precise wording
- ranges or approximate values
- explicit notes
- citations to DigitalAssets
Example:
"mentioned only once in a newspaper article"
is preferred over
"certainty = low".
Future extension
Structured certainty may be added only if clear analytical needs arise.
Until then, descriptive practice remains the standard.
Status
This document defines the agreed conceptual meaning of the entities – Version 3.2.
All ER diagrams, DBML definitions, schemas, and implementations must conform to these definitions.