Six responsibilities, one research workflow
A modular framework makes the route from source evidence to a citable release explicit.
01InitiatorDefine
02AggregatorCollect
03ProcessorInterpret
04ProspectorReview
05NavigatorExplore
06PersistorPreserve
| Component | Responsibility |
|---|---|
| Initiator | Shared schemas, migrations, integrity and data governance. |
| Aggregator | Approved source acquisition, transfer preparation and evidence retention. |
| Processor | Staging, normalization candidates, analysis and controlled canonical projection. |
| Prospector | Discovery of provisional literature, media and authority evidence. |
| Navigator | Source-aware public research projections and citations. |
| Persistor | Approved packaging, deposition and persistent identifiers. |
The framework distinguishes original source evidence, inference, canonical representation, dissemination and preservation. A public view is a projection of a data state; browsing that view should not silently rewrite the underlying evidence.
Supporting components
Monitor observes status and freshness without changing research data or running jobs. The musiXplora Bridge imports and explores versioned person snapshots. These components complement the six core responsibilities.
Trace one statement through the framework
Consider a source page that attributes a renovation to a named workshop. Acquisition first preserves the page and its source context. Processing can extract the statement, propose a normalized actor identity and attach a candidate role. A reviewed decision determines whether that interpretation becomes part of a canonical projection. Public exploration then presents the attributed result; release preparation fixes a publishable state.
| Boundary | What crosses it |
|---|---|
| Discovery → acquisition | A candidate source or update proposal, not an accepted historical fact. |
| Acquisition → processing | Identified source evidence and documented transfer records. |
| Processing → canonical projection | An explicitly reviewed interpretation with its supporting evidence. |
| Projection → public access | A research view retaining attribution and qualifications. |
| Approved output → preservation | A checked, versioned package with persistent release information. |
Why separate responsibilities?
A component that finds a promising page does not also decide that its claims are correct. A viewer that displays a convenient summary does not silently rewrite its evidence. A status monitor does not repair a failed job by changing the research data. These boundaries make it easier to identify who owns a decision, what can be replayed and which part of a workflow needs attention.
A framework is more than an execution chain
Real research revisits earlier stages. A new source can reopen an interpretation; a validation failure can return a candidate for review; a publication decision can restrict a public subset without deleting retained evidence. The diagram describes responsibilities and exchanges rather than a promise that every item passes through one automatic, irreversible sequence.
Discovery and publication have different contracts
Prospector finds potential publications, media, authority links and updates, then hands proposals into a reviewable workflow. It does not make every discovered identity canonical. Aggregator acquires approved material and preserves its source context. Processor returns candidates and derived evidence. Navigator exposes a research view, while Persistor prepares approved publication packages and stable release information. Initiator maintains the common structural and governance foundations.
Monitor contributes a separate operational view of health and freshness. A healthy service does not establish that a historical assertion is correct, and a stale service does not invalidate all retained research evidence. Keeping operational status and scholarly judgment separate makes both easier to interpret.
Sources & further reading
- Dominik Ukolov · Musikinstrumente im virtuellen Raum (2026)
Dissertation submitted to Universität Leipzig, 11 September 2026. Chapters 1–6 and 8; Appendix I.4 for the software and resource inventory. See the dedicated research guides for claim-specific section references. Page numbers refer to the printed manuscript pagination. The manuscript is not distributed by this website.
- MODAVIS Framework · component registry
Project component documentation inspected on 26 September 2026. Used for the division of responsibilities among Initiator, Aggregator, Processor, Navigator, Prospector, Persistor and supporting services.
- MODAVIS Processor · module guide and package README
Project documentation inspected on 26 September 2026; package 0.2.0, an unpublished development candidate. Used for current module responsibilities and limitations, not as a claim of public package availability.
Page editions 2026-09-r4 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
Edition 2026-09-r4 · SHA-256
43722b0bf391Page metadata ↗