Starting Point: Digital Assets (DA)

This page documents why the Digital Assets (DA) environment is the first implementation focus and how it should be approached during the initial phase.

It is intended as internal guidance for administrators and editors involved in the setup.

Why Start with Digital Assets

Digital Assets are the most critical and complex part of the system.

They sit at the intersection of:

MediaWiki file handling (File: namespace)
Access control and permissions
Metadata quality
Derivatives (OCR, thumbnails, translations, etc.)
Relationships to Heritage Objects and other entities
Public publication workflows

Decisions made here directly affect:

Data quality
Long-term maintainability
Safety of public publication

If the Digital Asset layer is well designed, all other parts of the system become simpler.

Role of Digital Assets

A Digital Asset (DA) represents a conceptual media object, not just a file.

A DA page may reference:

One or more physical files
Parent or child Digital Assets (derivatives)
One or more Heritage Objects
Internal notes and provenance information

DA pages are internal and are never public-facing content.

First Implementation Phase (Scope)

The first iteration of the Digital Assets environment must remain intentionally limited.

Included:

DA namespace
Cargo table for Digital Assets
Page Schema and Form for DA
Manual file uploads
Manual linking of files to DA pages

Explicitly excluded (for now):

Automated upload workflows
Public publication logic
Advanced validation rules
Integration with Heritage Objects
Performance optimization

Step-by-Step Initial Setup

Step 1: Namespace

Create the DA: namespace
Restrict page creation and editing to club members
Prevent casual or accidental page creation

Verify:

Pages can be created
Links and search work as expected

Step 2: Cargo Table

Create a minimal Cargo table for Digital Assets.

Initial fields should focus on:

Identifier
Linked files
Parent Digital Asset
Description and notes

The Cargo table page must be saved manually to activate the database table.

Step 3: Page Schema and Form

Using the Page Schemas UI:

Create a DigitalAsset page type
Link it to the Cargo table
Generate a form for data entry

The form should be simple and readable. Clarity is more important than completeness.

Step 4: File Handling Discipline

During the first phase:

Files are uploaded manually by club members
File naming conventions are agreed socially
Internal vs public intent is documented on DA pages
No technical enforcement is attempted yet

Digital Assets serve as the policy enforcement layer.

Step 5: Test with Real Data

Create:

At least 3–5 DA pages
DA pages with multiple files
At least one parent/child DA relationship

Evaluate:

Editor understanding
Form usability
Query clarity
Naming consistency

Adjust early if something feels awkward.

Queries as a Validation Tool

Simple Cargo queries should already be possible, for example:

List all files linked to a DA
List child Digital Assets of a parent
List Digital Assets by file format or role

If queries feel complex or unnatural, the schema should be revised before moving on.

Guiding Principles for DA Design

Digital Assets are metadata, not files
Files have no meaning without a DA
Internal complexity is acceptable
Public simplicity is mandatory
Conventions precede automation
Early clarity prevents later refactoring

When the First Phase Is Complete

The Digital Assets environment can be considered stable when:

Editors can create DA pages without assistance
File usage is clear and consistent
Relationships are understandable
No accidental public exposure occurs

Only then should the system expand to:

Heritage Objects (HO)
Relationship subtables
Publication workflows
Automation

Status

This page documents the agreed starting approach.

It should be revisited after the first implementation cycle.