Built on explicit agreements
Standards make it possible to exchange a research object without losing the meaning of its parts.
MODAVIS connects complementary standards rather than asking one format to do everything. The ontology describes meaning and relationships. VAO binds digital resources into an exchange and preservation contract. Repositories supply persistent version records.
| Layer | Role |
|---|---|
| MODAVIS Ontology Network | Semantic identities and evidence-qualified relationships. |
| VAO Standard | Manifest, resources, profiles, carriers and file integrity. |
| Persistent identifiers | Stable references to entities and exact releases. |
| Provenance | Documented source, transformation and editorial lineage. |
Established media and research-object formats remain useful within this architecture. A VAO is an integration envelope; it does not replace an audio format, a repository or a domain ontology.
The agreement at each boundary
| Boundary | Agreement needed |
|---|---|
| A source enters a research workflow | Identity, capture context, transfer structure and attribution. |
| A statement becomes a research representation | Semantic identity, evidence, interpretation and historical applicability. |
| A representation becomes an exchange package | Exact manifest, resources, profiles, rights and carrier mappings. |
| A package becomes a published release | Persistent version information, file identities and repository metadata. |
These agreements address different kinds of interoperability. Two applications can read the same audio encoding while disagreeing about which instrument state the recording represents. Two catalogues can use the same label while assigning it to different concepts. Interoperability therefore requires both usable bytes and an explicit account of their meaning.
Reuse established formats inside the envelope
VAO can identify realizations in established media and research formats, such as WAVE or FLAC audio, glTF geometry and MIDI or score data. The carrier adds the relationships, fixed identities and declared capabilities needed to interpret those realizations together. The chosen format still carries its own technical requirements; packaging a file does not make an incompatible renderer understand it.
Version the contract as carefully as the content
Record the exact schema, profile and vocabulary versions used by a release. A moving “latest” pointer can be convenient for discovering documentation, but it cannot identify the rules under which an earlier package was prepared. When migrating, keep the source release available and describe what changed. A successful migration creates an attributable successor rather than retroactively rewriting the old contract.
Which standard answers which question?
| Contract | Role in this ecosystem | Read the result as |
|---|---|---|
| JSON Schema Draft 2020-12 | Structural validation of the VAO JSON record, with the required format assertions. | A check of the encoded structure, alongside additional semantic rules. |
| JSON-LD 1.1 | Explicit mappings from JSON terms to linked-data identifiers and graph relationships. | A semantic interpretation under an identified context, not a replacement for the authoritative VAO JSON. |
| PROV-O | A vocabulary for entities, activities, agents and their provenance relationships. | An account of derivation and responsibility, not a certificate that the resulting assertion is true. |
| SHACL | Validation of an RDF data graph against declared shapes and constraints. | A report for a particular data graph, shapes graph and validation setup. |
| VAO profiles and carrier contracts | Capabilities, exact realizations, dependency closure and package exchange. | A version-specific interoperability claim whose scope must be stated. |
These contracts work at different layers. A JSON record may satisfy its schema while referring to an inappropriate historical state. A graph may satisfy its shapes while an underlying source remains disputed. PROV-O can express that an analysis was generated by an activity associated with an agent; it does not independently verify that the activity used a calibrated instrument. The domain model and the research method provide the interpretation around the technical contract.
For implementation, keep the relevant documents and contexts pinned with the release. Start with the project’s specified contract rather than substituting a newer vocabulary or a moving context URL. For reading, consult the official specifications below alongside the project-specific requirements. This separates the general mechanism from the particular agreement MODAVIS or VAO makes with its consumers.
Sources & further reading
- VAO Standard 0.5.0
The versioned specification and reference tools.
- MODAVIS Ontology Network 0.1.0
The published semantic model.
- W3C · JSON-LD 1.1
Official specification; consulted for contexts and linked-data representation.
- W3C · PROV-O
Official provenance ontology; entities, activities and agents.
- W3C · SHACL
Official graph-validation specification, including Core and SPARQL-based constraints.
Page editions 2026-09-r4 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
31151f26439aPage metadata ↗