Why MediaWiki (and not Omeka-S or Zotero)

This page explains the rationale for choosing MediaWiki as the technical platform for this project, instead of Omeka-S or Zotero.

It is intended for collaborators who are familiar with digital research tools but not with system architecture or MediaWiki extensions.

The goal is to provide sufficient context to understand later design documents without requiring technical expertise.

Initial Context

At the start of the project, two existing platforms were considered:

Zotero – for managing references and sources
Omeka-S – for publishing cultural heritage collections

Both tools are well-established and widely used.

However, as the research progressed, it became clear that neither tool fully matched the needs of the project.

What the Project Actually Requires

The project is not only about collecting items or references.

It requires the ability to:

Describe complex historical objects at multiple levels
Represent relationships between objects, people, places, and institutions
Handle uncertainty and interpretation explicitly
Structure research into overlapping periods or chapters
Manage large numbers of digital files and derivatives
Separate internal research work from public presentation
Allow the data model to evolve over time

These requirements go beyond what a simple collection or bibliography system can provide.

Limitations of Zotero

Zotero is excellent for:

Bibliographic references
Citation management
Personal or shared libraries

However, Zotero:

Treats items as flat records
Has limited support for complex relationships
Is not designed for narrative structuring
Is not intended as a publication platform
Cannot model historical entities beyond references

Zotero remains useful as a *supporting tool*, but not as the core research platform.

Limitations of Omeka-S

Omeka-S is designed for:

Publishing cultural heritage collections
Describing items with metadata
Linking items to vocabularies

However, Omeka-S:

Assumes relatively flat “items”
Is rigid once a data model is chosen
Handles hierarchy and recursion poorly
Does not support complex, evolving research structures well
Makes it difficult to separate internal research from public publication
Is less suitable for long-term exploratory research

Omeka-S is strongest when the structure is known in advance. This project requires the structure to emerge through research.

Why MediaWiki Was Chosen

MediaWiki is not a heritage platform by default.

Its strength lies elsewhere:

It is concept-centric, not item-centric
It supports gradual formalization
It allows separation between content, structure, and presentation
It scales well with complexity
It supports collaborative knowledge building
It can serve both internal and public audiences

Most importantly:

MediaWiki allows the research model to evolve without locking decisions too early.

How MediaWiki Is Used in This Project (Conceptually)

MediaWiki is used as a **knowledge platform**, not just a wiki.

Conceptually, the system distinguishes between:

Concept	Meaning
Heritage Objects	What is being studied (buildings, places, concepts)
Digital Assets	How something is represented digitally
Actors	Who was involved historically
Research Chapters	How the research is structured narratively
Files	Physical digital files (images, scans, PDFs)

These concepts exist independently of the technical implementation.

Why Additional Components Are Needed

MediaWiki core handles pages and files very well.

However, it does not natively support:

Structured data fields
Repeating relationships
Explicit modeling of uncertainty
Querying structured relationships

For this reason, additional components are used internally.

These components are **implementation tools**, not concepts.

Meaning of the Main Components (Non-Technical)

The following table explains the role of the main components without technical detail:

Component	What it does (conceptually)
MediaWiki	Provides pages, collaboration, and publication
Structured forms	Guide users when entering information
Structured storage	Ensures data is consistent and queryable
Internal documentation	Records design decisions and reasoning

Collaborators are not expected to understand or manage these components directly.

Internal vs Public Use

The system deliberately separates:

Internal research work
Public presentation of results

Internal work:

May be incomplete
May change
May include uncertainty and discussion

Public content:

Is curated
Is stable
Represents agreed results

This separation is difficult to achieve in Omeka-S or Zotero, but natural in MediaWiki.

What This Means for Collaborators

For most club members:

Interaction happens through forms
Concepts are visible, not technical mechanisms
No knowledge of MediaWiki internals is required
The system behaves like a structured research environment

Architectural complexity exists only to support clarity and flexibility.

How to Read the Other ICT Documents

The other ICT documents:

Architecture
Entity definitions
ER model
Workflow
Policy

are written to ensure long-term consistency.

They are not manuals, but shared agreements.

This page should be read first to understand the context in which those documents exist.

Status

This document explains the platform choice and conceptual approach.

It is intended to be stable and accessible to non-technical collaborators.