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. |
Cuntz · Illustrative scenario#
Where does an extracted number become an accepted claim?
A processing candidate is a proposed interpretation of source material. Review and publication are additional decisions, with their own evidence and responsibilities.
Work through the example 3 STEPS
Use the Cuntz workbook observation to imagine a new import workflow. This is an explanatory mapping to the Processor architecture, not a claim that the published Cuntz release was built by all current Processor modules.
Preserve the source
Intake identifies the workbook bytes and source context. Extraction retains the literal cell, property code and unit rather than keeping only a convenient normalized number.
Inspect the candidate
A normalizer can propose a structured observation and a pipe identity. A reviewer checks the cell interpretation, the identity match and qualifications such as the timestamp note.
Publish the accountable result
An accepted projection keeps the evidence link and decision. A public view can be concise while a fixed release preserves the record needed to re-examine the claim.
BASIS FOR THIS EXAMPLE
- Cuntz Positiv · VAO 0.5.0-rc.2 ↗
Published manifest: identities, measurement observations, realization digests, profiles and rights. Exact examples checked against this release.
- MODAVIS Ontology Network 0.1.0 ↗
Identity, state, configuration, evidence, assertions, context and provenance. Teaching examples explain its distinctions without inventing new normative properties.
The example illustrates component responsibilities without attributing unverified processing history to the actual release.
The useful distinction. Automation can propose a useful structure; an accountable workflow keeps the interpretation and its grounds inspectable.
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-r6 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
Edition 2026-09-r6 · SHA-256
aa00242a58bcPage metadata ↗