Landrace.Wiki:Mediawiki

This page explains how Landrace.Wiki works under the hood: the software stack, the data model and what happens when you add or edit content.

It is meant as a practical overview for contributors who want to understand what the wiki is doing and how to work with it instead of against it.

Software stack

Landrace.Wiki runs on:

• MediaWiki 1.44 – the same core software used by Wikipedia.
• Semantic MediaWiki 6.0.1 – adds structured data (properties) to pages, so content can be queried and reused.
• PageForms – provides forms for creating and editing structured pages without writing wikitext by hand.
• TemplateStyles – lets us attach CSS to templates in a controlled, portable way.

There is no separate, hidden application layer. What you see is what the software actually is: pages, templates, forms, and semantic properties.

Data model: pages + properties

Every piece of information on Landrace.Wiki lives on a page, and that page can carry structured data via semantic properties.

The main content types are:

• Geographic hierarchy pages – gene pools, regional complexes, growing regions, growing areas, appellations, and fields.
• Accession pages – individual collection events, with their own IDs, dates, and context.
• Concept and glossary pages – definitions, methods, and background terms.
• People / organization pages – fieldworkers, collectives, and partner groups.
• Media / documentation pages – field reports, trip notes, and supporting materials.

Semantic MediaWiki attaches properties to these pages (for example: elevation, GPS, collection year, conservation status). Queries then pull those properties back out to build tables, maps, and statistics.

Principles:

• Data is stored at the accession level wherever possible.
• Regions, areas, appellations and fields act as containers and context.
• Pages are the source of truth; views are just different ways of slicing those pages.

Forms: how you edit

Most structured pages are created and edited through PageForms.

Typical flows:

• Creating a new accession from a link like “Add accession” opens an Accession form.
• Creating or editing a region, area, appellation, or field opens the relevant Region form.
• Concept pages and some other pages may be edited directly, or via simpler forms.

When you submit a form:

• The form writes wikitext into the page using templates.
• That wikitext includes semantic properties.
• Those properties are immediately available to queries and views.

You do not need to know the property names or template syntax to contribute via forms. Advanced users can inspect and edit the underlying wikitext if needed, but the forms are the expected entry point.

Tiers and minimum documentation

Accession forms are structured around documentation tiers:

• Tier 1 – critical minimum conservation data (location, date, context, collector, basic plant/seed info).
• Higher tiers – additional environmental, agronomic, cultural, and analytical data as it becomes available.

The goal is to ensure every accession has enough information to be meaningful for conservation and research, while allowing deeper documentation over time.

Region, area, appellation and field pages follow a similar pattern: a small set of required fields, then more detailed sections that can be filled out as data and sources accumulate.

Views: lists, maps, and numbers

What you see on browse pages and region overviews is generated from semantic queries, not hard-coded lists.

Examples:

• Strain / accession lists for a given region are pulled from accessions linked to that region.
• Conservation filters (e.g. threatened, at risk, extinct) are based on stored status properties.
• Counts (number of accessions, number of regions with documented cultivation, etc.) are computed from the live data.

Implications:

• If a number looks low or a list looks incomplete, it usually means the underlying data has not been entered yet.
• Fixes are generally made by updating accessions or region pages, not by editing the list itself.

This keeps the site honest: numbers and lists change automatically as new data is added or old data is corrected.

Templates and styling

Layout and visual consistency are handled through templates and TemplateStyles:

• Page templates define standard sections and infobox-style summaries.
• TemplateStyles CSS is attached to those templates so that styling is reusable and self-contained.
• We avoid heavy custom JavaScript and external services where possible to keep the site portable and inspectable.

If a page looks “off” compared to others of the same type, it usually means it is missing a template call or was created before the current templates were adopted.

Why this setup

The MediaWiki + Semantic MediaWiki + PageForms stack is chosen because it:

• Uses only free and open-source software.
• Keeps content, structure, and presentation in plain text that can be exported, mirrored, or forked.
• Lets contributors see and understand how data is stored and where views come from.
• Avoids a fragile layer of custom code that only a few people can maintain.

Landrace.Wiki is meant to outlive any single server, maintainer, or interface. A transparent, page-based system built on widely used tools makes that realistic.

If you want to go deeper

If you are interested in the details:

• Look at the wikitext of an accession, region, or concept page to see which templates and properties are used.
• Explore the template pages themselves to understand the structure.
• From there, you can learn how queries are written and how new views (lists, tables, maps) are built.

For most contributors, you do not need to touch any of this to add good data. The forms and standard page layouts are designed so you can focus on fieldwork, documentation and sources, while the software takes care of structure and display.