Mngr: Created page with "= 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) * Acc..."

2026-01-17T16:55:18Z

Created page with "= 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) * Acc..."

New page

= 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.

ICT:Starting with DA - Revision history