Model an instrument through change
An instrument can survive a rebuild while its configuration, location and documented behavior change. The MODAVIS ontology keeps these relationships explicit instead of assigning every statement to an undifferentiated object.
A hypothetical organ with two documented states
Consider an illustrative organ described in a construction account and a later restoration survey. The first source lists an original disposition; the second records replacement pipes, a new location and a modified action. This is a modeling example, not an additional historical instrument claim. Begin with a proposed instrument identity, then represent the states, configurations, components and events supported by the two accounts.
| Entity or relation | In the example | Why it stays distinct |
|---|---|---|
| Instrument identity | The organ whose continuity is being investigated. | Identity is not reducible to one name, location or surviving component. |
| State | The instrument as documented at a particular phase. | A later survey should not overwrite what an earlier account says. |
| Configuration | The components and their functional arrangement in that state. | A register or mechanism can change without every other claim changing. |
| Historical event | Construction, relocation, repair or alteration supported by evidence. | An event in the object’s history differs from a database import or editorial action. |
| Source fragment | The exact passage or survey record supporting a statement. | Two descriptions may disagree or concern different phases. |
| Assertion and applicability | A claim about a property, with its relevant state and scope. | A statement valid for one phase is not automatically valid throughout the instrument’s life. |
The distinction makes disagreement informative. “The organ has this action” may be consistent with another source if the sources concern different states. If they concern the same state, retain the conflict and its evidence. A move does not automatically establish a new instrument identity, while a shared name does not establish continuity. The interpretation needs documented reasoning.
Applicability answers a different question from provenance
Provenance describes how a record was produced: source, extraction, processing and review. Context describes when and where the assertion applies. A modern cataloguer may make a claim about an eighteenth-century configuration; the date of cataloguing and the historical scope are different coordinates. In the ontology network, absent assertion context means unknown applicability, not universal applicability.
The network also distinguishes physical instruments from playable virtual-instrument products, versions and packages. A VAO can represent evidence about the physical organ and support a digital experience without becoming identical to that organ. A software package update need not represent a historical change, and a historical-state hypothesis need not coincide with a software release boundary.
Fourteen modules organize the distinctions
| Modules | Responsibility |
|---|---|
| Core; Instrument; Organ | Common identities, agents and places; states, configurations and components; organ-specific specialization. |
| Evidence; Provenance; Assertion | Source snapshots and fragments; processing and editorial lineage; claims, conflicts, decisions and projections. |
| Events; Context | Historical occurrences and the applicability conditions of statements. |
| Media; Audio; MIDI | Representations and bitstreams; fixed signals and frame regions; optional protocol bindings. |
| Virtual Instrument; Heritage; Vocabulary | Playable product and package identities; knowledge and collection snapshots; reviewed SKOS concepts. |
Validate relationships without inventing missing history
The release uses OWL distinctions and SHACL constraints, including SHACL-SPARQL, to check the model’s intended boundaries. Its validation contract includes the necessary class-hierarchy snapshot; it is not a license to populate missing domain facts through unrestricted inference. A constraint can reveal an inconsistent identity assignment or missing required relation. It cannot supply the undocumented builder of an instrument.
Stable HTTP identifiers are the normative identity route. Legacy MODAVIS identifiers can be retained for reconciliation without being promoted to a persistent-identifier guarantee. The ontology network also keeps its import closure separate from downstream VAO mappings, which are owned by the VAO specification. This lets the domain model serve research beyond any one package format.
Preserve a knowledge state as well as an object state
A historical state describes the instrument; a knowledge snapshot describes the research record at a given publication point. Those are independent. New evidence can revise a claim about an old state. The ontology’s snapshot approach makes membership and graph identity explicit, with canonical graph hashing metadata kept outside the hashed content. This helps a reader recover what a release asserted without pretending that its interpretations are final.
Sources & further reading
- MODAVIS Ontology Network 0.1.0
Release README, fourteen module descriptions and SHACL validation contract.
- Dominik Ukolov · Musikinstrumente im virtuellen Raum (2026)
Dissertation submitted to Universität Leipzig, 11 September 2026. §§3.2.4–3.2.7; §§4.4.3–4.6 on identity, sources and non-destructive integration. Page numbers refer to the printed manuscript pagination. The manuscript is not distributed by this website.
Page editions 2026-09-r4 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
Edition 2026-09-r4 · SHA-256
bf7b946667bcPage metadata ↗