1 BioSim CZ overview

This section presents the overview and necessary context for the BioSim CZ repository. BioSim CZ is intended to provide storage, management, access, and further processing for structural simulation data concerning 3D structures of biomacromolecules.

See the Glossary for definitions of domain and platform terms.

1.1 Purpose and Current Target

This document describes BioSim CZ as a repository for structural simulation data. The current architecture target is the prototype, corresponding to feasibility-study output B_2.1.

The prototype architecture focuses on molecular dynamics (MD) data and covers:

• the prototype repository architecture,
• the metadata extraction and FAIRification flow,
• the molecular-dynamics metadata schema.

The complete-version goals are mentioned only where they provide context for the prototype scope or future development direction.

1.2 Source Basis and Traceability

The architecture reflects the requirements described in BioSim CZ feasibility study. The relevant feasibility-study outputs are:

1.3 Project Context

BioSim CZ is the Czech repository for structural simulation data. It is part of the NRP and is implemented using CESNET Invenio.

1.4 Prototype Scope and Development Direction

BioSim CZ is developed in two stages: a molecular-dynamics prototype followed by a complete version with broader data coverage and external integrations.

1.4.1 Current Prototype Scope

The prototype is the current architecture target. It is limited to MD data and covers:

• creation of a dataset,
• upload, storage, publication, discovery, download, and sharing of MD data through the standard CESNET Invenio publication, access, and download behaviour,
• repository-side metadata processing for MD data:
  • metadata extraction from GROMACS molecular-dynamics data,
  • normalization and conversion of extracted metadata into an engine-agnostic MD metadata schema,
  • basic validation needed for metadata extraction, metadata mapping, and user review.
• assignment and display of a human-readable BioSim CZ accession identifier for each published dataset,
• DOI registration support in a test mode,
• metadata-based discovery by text search, metadata filters, PDB ID, and UniProt ID.

1.4.2 Complete-Version Scope

The prototype does not target the full BioSim CZ scope. The following areas are the complete-version goals:

• support for coarse-grained simulations,
• support for predicted structural ensembles,
• functional MDDB integration,
• ELIXIR CZ, bio.tools, PDBe-KB, and 3D-Beacons integration,
• structure-based search using uploaded PDB format or mmCIF structures,
• the system of user roles and access rights,
• DOI registration support,
• external dataset import from repositories such as Zenodo, Figshare, OSF, or similar sources,
• downstream computational processing and analysis services for simulation data,
• advanced scientific consistency checking across simulation data.

Please do note that the complete-version scope is a directional target, not a prototype commitment. It positions the intended future role of BioSim CZ, but individual capabilities may change after prototype validation and later project decisions.

1.5 Interoperability Context

BioSim CZ is planned as the Czech national node in the BioExcel MDDB / MDposit context. It is also expected to be visible through ELIXIR CZ and bio.tools, with later connections to biomolecular-structure resources such as PDBe-KB and the 3D-Beacons Network.

1.6 Basic Information

Note that the provided URLs are reserved but might not be active as an instance of BioSim CZ is not deployed yet.

1.7 Team Members

2 BioSim CZ Prototype Architecture

This section describes the architecture of the BioSim CZ prototype.

2.1 Prototype High-Level Architecture

The BioSim CZ prototype is implemented as a domain-specific extension of the NRP. The platform provides the common repository capabilities, while BioSim CZ adds the domain model, user-facing metadata workflow, and molecular dynamics-specific metadata extraction.

flowchart TB
    Platform["CESNET Invenio<br/><span style='font-size:12px;color:#666'>Base repository functionality, records, files, identifiers, DOI registration support, authentication, persistence, and common metadata infrastructure, including CCMM</span>"]

    subgraph BioSim[BioSim CZ domain extension]
        DataModel[Data model] ~~~  MetadataModel[Metadata model] ~~~ Extraction["Metadata extractors<br/><span style='font-size:12px;color:#666'>Initial extraction from GROMACS inputs into the common MD metadata model</span>"]
        UI[Prototype UI]
        UI --> MainPage[Main page]
        UI --> DepositForms[Deposit forms]
        UI --> Browse[Browse datasets page]
        UI --> Detail[Dataset detail page]
    end
    Platform --> BioSim

2.2 Data and Metadata Model

BioSim CZ separates the data model from the metadata model. The data model defines the main repository entities and their relationships. The metadata model defines descriptive fields attached to those entities.

The proposed data model relies on interlinked, also referred to as hierarchical, records in CESNET Invenio. This capability is expected to be implemented before the prototype release.

2.2.1 Conceptual Data Model

BioSim CZ uses Study as the top-level repository record. A Study represents one coherent deposited dataset and is the main unit of publication, search, citation, and repository lifecycle.

A Study contains one or more Experiments. An Experiment represents a concrete computational setup or run within the Study. Experiments are lifecycle-bound to the parent Study, are published together with it, and are not independently citable.

Files are associated with individual Experiments, not with the Study as a whole. This allows each Experiment to have its own input files, output files, software context, and extracted metadata.

flowchart LR
    Study -->| 1..N| Experiment
    Experiment -->| 1..N| File

The interlinked-record structure defines the persistence boundary: the Study owns the publication lifecycle, while each Experiment owns its associated files and extracted metadata within that Study.

2.2.2 Conceptual Metadata Model

The BioSim CZ metadata model is layered. Common repository metadata is provided by CCMM. BioSim CZ adds domain metadata describing the studied object and study-type-specific metadata for simulation or ensemble records.

Each Study has a type:

• MD - molecular dynamics study
• CG - coarse-grained (CG) simulation study (not available in the prototype)
• ensemble - predicted or structural ensemble study (not available in the prototype)

flowchart LR
    StudyMetadata[Study metadata] --> Generic["CCMM metadata<br/><span style='font-size:12px;color:#666'>(such as title, creators, description, license, funding, and related identifiers)</span>"]
    StudyMetadata --> StudiedObject["Studied object metadata<br/><span style='font-size:12px;color:#666'>Description of the molecular or structural object being studied <br /> (such as protein, complex, ligand, using studied-object identifiers)</span>"]
    StudyMetadata --> StudyTypeEnum["Study type<br/><b>MD</b>, <b>CG</b>, <b>ensemble</b>"]
    StudyMetadata --> StudySpecific[Study-type-specific metadata]
    StudySpecific --> Choice{one of}
    Choice -->|MD| MD[MD metadata]
    Choice -->|CG| CG[CG metadata]
    Choice -->|ensemble| Ensemble[Ensemble metadata]

Individual Experiments within a Study have their metadata automatically extracted from the uploaded data (except for optional user-provided name and description).

flowchart LR
    ExperimentMetadata[Experiment metadata] --> Name[Name and description]
    ExperimentMetadata --> Files[Files]
    ExperimentMetadata --> Extracted["Extracted metadata<br/><span style='font-size:12px;color:#666'>Specific to the Study type</span>"]

2.2.3 MD Engine Scope

The BioSim CZ MD metadata model is engine-agnostic: it stores common molecular-dynamics concepts rather than fields tied to one simulation package.

In the prototype, automatic metadata extraction is limited to GROMACS. Other MD engines, such as AMBER, NAMD, OpenMM, or CHARMM, remain future work. They should be supported through engine-specific extractors that populate the shared BioSim CZ MD metadata model, once their file requirements, extractable metadata, validation rules, and field mappings are defined.

2.3 Study Identifiers and DOI Registration

The prototype distinguishes platform-level technical identifiers from BioSim CZ accession identifiers. CESNET Invenio may maintain technical record identifiers for persistence, routing, and internal record management. These technical identifiers are not the primary human-facing citation identifiers in the BioSim CZ prototype.

Each published Study receives a human-readable BioSim CZ accession identifier. The accession identifier is stable within BioSim CZ and is displayed in search results, dataset detail pages, exports, and citation guidance. The prototype uses this accession identifier as the local user-facing persistent identifier for the citable Study record.

For publication use, the accession identifier should be cited together with the stable BioSim CZ landing-page URL of the Study. The landing page is the resolvable access point for the dataset. A suggested resolution pattern is https://biosim.cz/records/{accession}, for example https://biosim.cz/records/MD_000001.

The recommended accession format is:

• MD_000001 for molecular dynamics Studies,
• CG_000001 for coarse-grained simulation Studies,
• EN_000001 for ensemble Studies.

The prototype only assigns MD_* identifiers because only molecular dynamics Studies are supported.

DOI registration is provided by CESNET Invenio and does not require a separate BioSim CZ DOI provider integration. In the prototype, DOI registration is exercised only in the platform sandbox/test setup, so no production DOIs are registered. When DOI registration is enabled for testing, DOI records should resolve to the stable BioSim CZ landing page of the Study, using the same landing-page pattern as the accession identifier, for example https://biosim.cz/records/MD_000001.

Experiments may be referenced by subordinate internal identifiers scoped to the parent Study, for example MD_000001-EXP_0001. Experiment identifiers are not independent citable persistent identifiers and do not receive independent DOIs in the prototype; they identify nested Experiments inside the citable Study.

2.4 Prototype FAIRification

In the prototype, FAIRification means the repository and metadata workflow that improves alignment with FAIR principles for molecular-dynamics Studies. It is not a separate component and does not imply production DOI registration or complete scientific consistency checking.

At the architecture level, prototype FAIRification is provided by the combination of:

• the Study as the citable repository record;
• the BioSim CZ accession identifier assigned to each published Study, with DOI registration exercised through CESNET Invenio in sandbox/test mode;
• CCMM generic metadata, including creators, licencing, or funding;
• BioSim CZ Study and Experiment metadata for molecular-dynamics data;
• studied-object identifiers such as PDB ID and UniProt ID where provided;
• metadata extraction from GROMACS inputs into the common MD metadata model;
• controlled vocabularies and documented unit normalization in the MD metadata model;
• depositor review of extracted and entered metadata before publication.

These mechanisms support findability through identifiers and indexed metadata, accessibility through repository publication and file download, interoperability through shared schemas and vocabularies, and reusability through provenance, license metadata, and reviewed extracted metadata.

2.5 User Workflows

BioSim CZ supports two primary user scenarios: depositing a dataset and discovering an existing dataset.

2.5.1 Deposition Workflow

A user deposits a molecular dynamics dataset:

1. Create a new Study record.
2. Enter generic Study metadata (title, creators, description, license, funding, related identifiers).
3. Enter studied-object metadata (e.g., PDB ID or UniProt ID).
4. Select the study type MD. (CG and ensemble are disabled in the prototype.)
5. Add one or more Experiments to the Study.
6. Upload files to each Experiment.
7. Trigger automatic metadata extraction from deposited files.
8. Review and submit the Study for publication.

2.5.2 Discovery Workflow

A user finds and accesses a published MD dataset:

1. Search or browse published Studies by text search, Study and Experiment metadata filters, accession identifier, or studied-object identifier (e.g., PDB ID, or UniProt ID).
2. Inspect Study metadata (e.g., studied objects or study type).
3. Open a Study to view its detail.
4. Browse Experiments within the Study.
5. Inspect Experiment metadata (e.g., simulation setup or thermodynamic conditions).
6. Download files associated with an Experiment.

2.6 Prototype Verification Scope

Prototype verification demonstrates that the deposition and discovery workflows described above can be exercised with representative deposited data. The verification dataset scope includes representative molecular dynamics datasets, with automatic extraction initially limited to GROMACS inputs. Where available, test data should include data from the involved and collaborating institutions named in the feasibility study. Verification should include successful workflow execution and expected metadata-extraction warning or failure cases.

3 BioSim CZ Prototype Metadata Model

The BioSim CZ repository’s records use a custom BioSim CZ metadata model, which layers domain-specific metadata on top of CCMM. Generic metadata, including title, creators, contributors, contact person, description, license, funding, and related identifiers, are provided by CCMM and are not repeated here. This document describes only the BioSim CZ extensions.

MOLSIM, an ontology for describing atomistic biomolecular simulations, is used as a terminology-alignment and traceability source for molecular-simulation concepts. Where applicable, selected schema fields and controlled-vocabulary values are mapped to MOLSIM concepts so that extraction decisions, user-facing terms, and future interoperability work remain traceable. The mapping is done through the comments in respective YAML files.

The complete prototype metadata schema, including all YAML schema files and controlled vocabularies described in this chapter, is available as biosimcz-prototype-metadata.zip.

3.1 Study-level metadata

A Study is the top-level citable unit. In addition to CCMM generic metadata, it carries:

Schema: metadata/schemas/study/study.yaml

3.1.1 studied_objects

An array of study object identifiers. Each entry declares its identifier type using id_type, provides the identifier value, and may include an optional description.

Variant details:

3.1.2 Type-specific metadata

The metadata object records fields that describe the Study as a whole and depend on study_type. In particular, they classify the deposited dataset and its intended methodological framing, but do not duplicate concrete run parameters extracted from files.

3.1.3 MD Study metadata

The MD Study metadata describes dataset-level properties that are meaningful for the citable Study as a collection of experiments. It captures how the deposited MD dataset is organized, what methodological intent it represents, and how that intent should be presented for discovery and reuse. It does not store software version, force field, thermodynamic state, timestep, simulation length, system size, files, or extraction provenance; those remain Experiment metadata.

These Study-level fields are relevant because a citable Study can contain one run, several replicas, a parameter sweep, or a workflow whose meaning is not fully described by individual extracted run parameters.

3.2 Experiment-level metadata

An Experiment is a concrete computational setup or run nested within a Study. Experiment metadata is divided into fields common to all experiments and fields specific to the experiment type.

Schema: experiment/experiment.yaml

The extraction_provenance object is stored on the Experiment because automatic extraction produces Experiment metadata. Its schema is separated from the Experiment envelope in experiment/definitions/extraction_provenance.yaml. It is present only when automatic extraction has been attempted. Detailed workflow semantics, including extraction roles, statuses, messages, and rerun behavior, are defined in Metadata extractors.

3.2.1 Files (files)

Files are attached to individual Experiments. The files array records the Experiment-level file attachments and assigns each file a domain semantic type. The semantic type may be suggested by the deposit workflow and then confirmed or corrected by the depositor; extraction-specific source-file roles are recorded separately in extraction provenance. This keeps input files, output files, extraction sources, and extracted metadata under the same Experiment boundary.

3.2.2 Type-specific metadata

The metadata object declares its experiment type using experiment_type. The selected type determines which additional fields are expected.

Note that the value of experiment_type must be compatible with the parent Study’s study_type. A Study typed MD may only contain Experiments with experiment_type: MD.

3.2.3 MD Experiment metadata

The MD experiment type groups fields into four logical sections:

• Simulation Setup
• Thermodynamic State
• Temporal Extent
• System

Note that these sections organize the metadata; they are not separate records.

The MD Experiment metadata schema is engine-agnostic. The software field identifies the simulation engine, but the schema stores common MD concepts such as force field, timestep, number of steps, thermodynamic state, and system size. Prototype automatic extraction is currently specified only for GROMACS.

Fields populated by automatic extraction are treated as extractor-derived metadata and are reviewed by the depositor before submission.

Extractor-derived MD fields are optional in the common MD Experiment schema. Missing values mean that the source value is absent, unreadable, unknown, ambiguous, or not applicable. Missing values are reported through extraction messages and reduce metadata completeness, but do not by themselves block publication.

Schema: schemas/experiment/types/experiment_md.yaml

Note that all numeric values are stored in standard MD units (K, bar, ns, fs, nm/deg).

Controlled-vocabulary fields store BioSim CZ vocabulary identifiers. The current file and MD vocabularies include other for known values outside the curated term list; unavailable, unknown, or ambiguous extractor values are left empty and reported through extraction messages.

3.2.3.1 Simulation Setup (simulation_setup)

3.2.3.2 Thermodynamic State (thermodynamic_state)

3.2.3.3 Temporal Extent (temporal_extent)

3.2.3.4 System (system)

4 BioSim CZ Prototype Metadata Extractors

The prototype metadata extractor turns uploaded GROMACS files for an Experiment into BioSim CZ molecular-dynamics Experiment metadata.

The extractor scope is limited to technical simulation metadata that can be mapped to the prototype metadata model. Study-level descriptive metadata, such as title, creators, publication information, and studied-object identifiers, remain part of the Study metadata workflow and are not the primary responsibility of the extractor.

4.1 Architectural Position

The extraction component sits between Experiment file upload and repository validation. It separates engine-specific file handling and metadata extraction from mapping into the common BioSim CZ metadata model.

Each engine profile follows the same boundary:

• file classification and required/optional input detection;
• engine-specific extraction into engine-native technical metadata;
• adaptor mapping into the BioSim CZ MD Experiment metadata schema;
• recording the latest extraction status, selected source files, and stage-level messages;
• repository validation and depositor review;
• saving reviewed metadata in the Experiment when the user submits the Study.

flowchart TD
    Files["Uploaded Experiment files"]

    subgraph EngineExtraction["Engine-specific extraction"]
        Profile["File classification<br/><span style='font-size:12px;color:#666'>Apply file profile and check required inputs</span>"]
        Extractor["Extractor<br/><span style='font-size:12px;color:#666'>Produce engine-native technical metadata</span>"]
        Profile --> Extractor
    end

    NativeMetadata["Engine-native extracted metadata"]

    subgraph BioSimMapping["BioSim CZ mapping"]
        Adaptor["Engine-specific adaptor<br/><span style='font-size:12px;color:#666'>Select, normalize, convert, and derive fields</span>"]
    end

    Metadata["Common BioSim CZ MD Experiment metadata"]

    subgraph ReviewStage["Repository validation and depositor review"]
        Review["Validation and review<br/><span style='font-size:12px;color:#666'>Check required fields, warnings, and provenance</span>"]
    end

    Saved["Saved reviewed Experiment metadata"]

    Files --> EngineExtraction
    EngineExtraction --> NativeMetadata
    NativeMetadata --> BioSimMapping
    BioSimMapping --> Metadata
    Metadata --> ReviewStage
    ReviewStage --> Saved

    classDef artefact fill:#d5f0a3,stroke:#9fca6b,stroke-width:1.5px,color:#2f3f2f;
    classDef phase fill:#fff4d6,stroke:#d6a700,stroke-width:1.5px,color:#3f2a10;
    class Files,NativeMetadata,Metadata,Saved artefact;
    class Profile,Extractor,Adaptor,Review phase;

    style EngineExtraction fill:#fffaf0,stroke:#d6a700,stroke-width:2px,stroke-dasharray: 6 4
    style BioSimMapping fill:#fffaf0,stroke:#d6a700,stroke-width:2px,stroke-dasharray: 6 4
    style ReviewStage fill:#fffaf0,stroke:#d6a700,stroke-width:2px,stroke-dasharray: 6 4

This separation keeps the repository metadata model independent of engine-specific field names. In the prototype, the general pattern is instantiated only by the GROMACS extraction profile. Extractor and adaptor outcomes are recorded together in the Experiment’s extraction_provenance object so that a successful engine extraction can still report adaptor warnings when values cannot be normalized into the common schema.

The Study is the submitted repository record; Experiments are parts of the Study and are not submitted separately. Prototype publication does not require curator approval when required fields, required files, and automatic checks are complete.

4.2 GROMACS Extraction Profile

The prototype uses the technical simulation and system output produced by GROMACS MetaDump as the GROMACS-native extraction source. The GROMACS profile applies the general components as follows:

4.2.1 GROMACS File Profile

The GROMACS profile defines how uploaded files participate in the Experiment and in the GROMACS MetaDump extraction run.

Each file is classified by a semantic type from the BioSim CZ vocabularies/file_semantic_type.yaml vocabulary, which is aligned with MOLSIM molecular data format classes. The repository may suggest the semantic type from the filename extension and selected GROMACS profile, but the depositor confirms or corrects the classification before extraction. The guided GROMACS path requires exactly one selected .tpr file classified as run_input; this file is the primary source for GROMACS MetaDump extraction.

Files are presented to the depositor with requirement levels:

When several files share a semantic type, the depositor selects which file, if any, is used as the .top or .gro MetaDump input; only one selected file per optional MetaDump input role is allowed. Multiple secondary files with the same semantic type may remain attached to the Experiment when they are not selected as MetaDump inputs. Missing recommended .top or .gro files reduce the amount or confidence of extracted metadata, but do not block extraction. A missing, unreadable, unsupported, ambiguous, or duplicated selected .tpr prevents automatic GROMACS extraction and blocks publication of the parent Study in the guided prototype MD deposit path.

4.2.2 GROMACS Extractor

The GROMACS extractor uses GROMACS MetaDump to produce GROMACS-native technical metadata from supported GROMACS files.

For BioSim CZ, the relevant extracted areas are:

• simulation setup and input-record parameters,
• thermodynamic settings,
• temporal extent,
• system size and box information,
• force-field and water-model hints when available.

The extractor output is not stored directly as BioSim CZ metadata. It is first passed to the BioSim CZ GROMACS adaptor.

4.2.3 BioSim CZ GROMACS Adaptor

The BioSim CZ GROMACS adaptor maps selected GROMACS-native values into the BioSim CZ MD Experiment metadata schema described in the prototype Metadata model.

The following table shows the prototype mapping from the example GROMACS extraction output to the BioSim CZ MD Experiment metadata schema.

Adaptor rules:

• BioSim CZ stores normalized MD concepts, not a raw GROMACS parameter dump.
• Controlled-vocabulary fields are closed during extraction and deposition normalization: stored values must be terms from the corresponding BioSim CZ vocabulary.
• GROMACS timestep values are interpreted in ps and converted to fs for metadata.temporal_extent.timestep.
• Simulation length is computed from dt * nsteps when both values are available and converted from ps to ns.
• Box lengths are stored in nm.
• Derived fields, such as ensemble, simulation_length, and box_type, are computed only when the source fields are sufficient.
• The current BioSim CZ file and MD vocabularies include other for known values that are outside the curated term list.
• If a source value is unavailable, unknown, or ambiguous, the normalized field is left empty and an adaptor warning is recorded.

4.3 Extractor Validation and Depositor Review

Prototype validation is limited to checks needed to run extraction, map metadata, and let the depositor review the result before submission.

The prototype-level checks are:

• required extraction input is missing;
• uploaded file is unreadable;
• uploaded file format is unsupported by the extraction profile;
• controlled-vocabulary value is unknown or ambiguous;
• unit conversion fails;
• derived field is ambiguous;
• optional extraction input is missing.

Missing optional files should be shown as informational warnings and recorded in extraction provenance. They should not prevent extraction when the required input is available.

Publication checks distinguish the profile errors described in the GROMACS File Profile from incomplete extracted metadata. A failed extraction or adaptation status blocks the guided GROMACS deposit path. By contrast, missing extracted fields or values normalized to other after a non-failed run, reduce metadata completeness and produce messages but do not by themselves block publication.

4.3.1 Extraction provenance

Extraction provenance is the Experiment-level record of the latest automatic extraction and adaptation attempt. It connects the reviewed BioSim CZ MD Experiment metadata back to the extraction profile, selected source files, processing stages, and diagnostics that produced it.

Schema: experiment/definitions/extraction_provenance.yaml

The provenance object records:

• engine type and selected extraction profile;
• extractor, adaptor, and extraction timestamp;
• overall status for the latest attempt;
• selected source files and their extraction roles;
• messages from the file_profile, extractor, or adaptor stage.

The prototype keeps only the latest extraction state for a draft Experiment. Rerunning extraction replaces the previous provenance object and automatically extracted metadata while leaving user-provided fields such as Experiment name and description editable. This latest-attempt model avoids mixing diagnostics and extracted values from different file-role selections.

Extraction messages provide diagnostics for depositor review. Raw source values related to unavailable, unknown, ambiguous, or otherwise non-stored normalized metadata may be included only in compact, safe diagnostic messages. They are not stored as normalized BioSim CZ metadata. The prototype stores file-level and stage-level messages only; it does not store field-level mapping diagnostics or full raw extractor output.

Depositor review is a confirmation and correction-boundary step, not a manual metadata editing step for automatically derived fields. The depositor can inspect extracted values, warnings, source files, and extraction provenance. If the result appears wrong, for example because the wrong file was uploaded or assigned to the wrong role, the depositor corrects the files or file-role bindings and reruns extraction. Rerunning extraction in a draft replaces the previous extracted metadata and provenance. User-provided fields, such as Experiment name and description, remain editable through the deposit form.

4.4 Future Engine Extraction Profiles

The GROMACS profile is the only extraction profile specified for the prototype. The architecture remains open to other molecular-dynamics engines, but they are not prototype-supported extraction profiles until their file profiles and extraction rules are documented from source material.

Future profiles for AMBER, NAMD, OpenMM, CHARMM, or similar engines should use the same architectural pattern described in this chapter. For each future profile, the missing work is not the repository boundary, but the source-backed definition of files, extraction behaviour, validation limits, and mappings.

5 BioSim CZ Prototype UI

The following screenshots document mockup UI views of the BioSim CZ prototype. They illustrate how the prototype architecture exposes Study, Experiment, metadata, deposition, and discovery workflows to users.

5.1 Main Page

The Main page follows a search-first principle. The primary action is to search existing records, while deposition is available as a secondary but visible action for authenticated contributors.

The page intentionally keeps the entry point simple: users can either search by free text, identifier, molecule, method, or related term, or start a new deposition workflow.

5.2 Deposit Form

The deposition workflow is organized around the Study / Experiment distinction used by the prototype metadata model.

5.2.1 Study

The Study step captures metadata that applies to the top-level citable record. This includes title, description, license, study type, structured creators, funding references, and studied objects.

Creators are represented as structured persons rather than a single free-text field. The fields reflect CCMM-relevant concepts such as person name, ORCID identifier, and affiliation.

5.2.2 Experiment

The Experiment step captures concrete computational setups or runs nested under the Study. In the prototype, the guided software profile is limited to GROMACS.

The GROMACS profile pre-fills expected file roles directly in the upload panel. This merges file guidance and file binding: the depositor sees which files are expected, why they are relevant, and how each uploaded file will be interpreted. The same step provides the entry point for metadata extraction from uploaded files. Automatically extracted metadata are shown for review but are not directly editable in the normal deposit form; if the result is wrong, the depositor corrects the uploaded files or file-role bindings and reruns extraction.

5.3 Browse Datasets

Browsing datasets supports faceted discovery of Studies. The filters expose both general repository metadata and simulation-specific parameters.

Result cards summarize the information needed for quick evaluation: identifier, creation date, authors, method, short description, and a structural preview where available. Simulation parameter filters allow users to narrow results by MD-specific properties such as ensemble, simulation length, timestep, temperature, pressure, thermostat, and barostat.

5.4 Dataset Detail

The detail view is split into three related pages.

5.4.1 Study Detail

The Study detail view shows the citable record with title, creators, dataset classification, and studied objects. The sidebar provides citation guidance with accession identifier and DOI.

5.4.2 Experiments List

The Experiments tab lists nested Experiment records with a table of Experiment IDs and names. Common MD metadata is shown once, followed by a differences table.

5.4.3 Experiment Detail

The Experiment detail view shows extracted MD metadata. Individual files are listed with semantic types and download links. The sidebar shows the Study hierarchy and navigation back to the Experiments list.

6 Glossary

This glossary defines domain and platform terms used in the architecture documentation. Definitions are written to be understandable without following project links.

6.1 Terms