The Ontology of Spatial and Immersive Audio: How Spatial9 Models Sound in 3D

• Basics & science

Spatial9 Engineering Team · Nov 2, 2026 · 14 min read

Ask five engineers what "an object" is in an immersive mix and you can get five answers: a track in the session, a sound with position metadata, an ADM audioObject, a game engine emitter, or anything that is not in the bed. That ambiguity is cheap in a single studio. It becomes expensive when a catalog of 50,000 tracks moves between a separation model, a renderer, a distributor and an AI agent that has to decide what to do with each file.

This guide is for audio engineers, data engineers and developers building on Spatial9. It explains the core ideas of ontology engineering in plain terms, applies them to spatial audio, shows how the main industry standards fit in, and walks through how Spatial9 uses the model in practice. Every code sample is commented, and the ontology itself is free to download: spatial-audio.ttl.

At a glance

Ontology in four building blocks

Ontology engineering comes from philosophy (the study of what exists) by way of computer science, where it means writing that down precisely enough that software can use it. The W3C standards RDF, OWL 2 and SHACL are the most common way to do it. You only need four ideas.

1. Classes are kinds of things: AudioObject, ChannelBed, Listener, Room.
2. Properties connect things or give them values: an object hasPosition, a renderer is renderedFor a listener, an element has gainDb -6.
3. Individuals are the real examples: lead_vocal_v2, bed_7_1_2, the room called studio_A.
4. Axioms are rules: every audio object has exactly one position, azimuth stays between -180 and 180 degrees, a channel bed is never also an audio object.

Taxonomy versus ontology

A taxonomy is a tree of "is a kind of": Instrument, then Strings, then Violin. It is great for menus and tags, and the W3C SKOS standard is built for it. An ontology adds every other relationship: the violin is played in a stem, which is carried by an audio object, positioned at 30 degrees left, heard by a listener in a room. Search needs a taxonomy. Reasoning about a mix needs an ontology.

Open world, closed checks

OWL assumes an open world: if a fact is missing, it is unknown, not false. That is right for a catalog that grows over time, but wrong for quality control, where "this object has no position" must be an error. That is why practical systems pair OWL (what things mean) with SHACL (what a valid record must look like). Spatial9 does the same.

The spatial and immersive audio ontology

Here is the model Spatial9 uses, grouped into five families. Each family answers a different question about a mix.

Content: recording, stem, instrument

A Recording is one captured performance of a song. It can be separatedInto Stems (vocals, drums, bass, other), and each stem plays one or more Instruments. This family aligns with the Music Ontology, where a recording is a mo:Signal derived from a mo:Performance of a mo:MusicalWork. Reusing those terms means a Spatial9 catalog can be joined with music metadata that already exists on the web.

Structure: mix and mix presentation

A Mix is one immersive version of a recording. A Mix Presentation is what a player actually renders: a chosen set of audio elements with their gains and loudness. The term comes from IAMF, and it maps closely to the ADM audioProgramme. Separating the two lets one mix carry several presentations, for example a full mix and a dialogue-forward or instrumental version.

Spatial elements: bed, object, scene

There are three ways to store sound in space, and they are disjoint: one element is exactly one of them.

• Channel Bed: audio tied to fixed speaker positions, such as 7.1.2 or 5.1. In ADM this is the DirectSpeakers type. In IAMF it is a channel-based audio element.
• Audio Object: a sound with its own position (azimuth, elevation, distance), width and gain, which can change over time. In ADM this is the Objects type with audioBlockFormat entries.
• Ambisonic Scene: the whole sound field around a point, stored at an order such as first or third. In ADM this is the HOA type. In IAMF it is a scene-based audio element.

Each element carries one or more stems. This is the bridge between "what the music is" and "where it is".

Playback: renderer and format

A Renderer turns a mix presentation into speaker feeds or a binaural headphone signal, and encodes the result into a Format: Eclipsa Audio (IAMF), ADM BWF, Dolby Atmos or binaural stereo. Treating format as a class, not a file extension, lets one query ask "which mixes have every format a distributor needs?"

Perception: listener, room, HRTF

The same mix sounds different to different people in different places. A Listener has a head position and orientation. A Room can be a real studio or an acoustic digital twin. An HRTF (head-related transfer function) describes how a particular head and ears filter sound, and is usually stored as an AES69 SOFA file. A renderer usesHRTF and is renderedFor a listener inRoom. Modelling perception explicitly is what makes personalised binaural and room-aware rendering possible.

How the standards fit together

You do not need a new standard. You need one model that lines up the good ones that exist.

Research projects have also explored audio ontologies, including the Studio Ontology for production workflows and the Audio Commons Ontology for sound content. They are good further reading.

Writing it down: Turtle, JSON-LD and rules

Here is one vocal object from a real mix, written in Turtle, the most readable RDF syntax. The full vocabulary is in spatial-audio.ttl.

@prefix s9:  <https://spatial9.ai/ontology/spatial-audio#> .
@prefix ex:  <https://catalog.example.com/> .

ex:song_0042        a s9:Recording ;
                    s9:separatedInto ex:song_0042_vocals ;   # produced by stem separation
                    s9:hasMix ex:song_0042_mix_v2 .

ex:song_0042_vocals a s9:Stem ;
                    s9:plays ex:LeadVoice .                  # an Instrument individual

ex:song_0042_mix_v2 s9:presents ex:song_0042_main .           # what the player renders

ex:song_0042_main   a s9:MixPresentation ;
                    s9:hasElement ex:vox_object , ex:bed_712 .

ex:vox_object       a s9:AudioObject ;
                    s9:carries ex:song_0042_vocals ;
                    s9:width 0.15 ;                           # narrow, focused vocal
                    s9:hasPosition [ s9:azimuth 0 ; s9:elevation 5 ; s9:distance 0.8 ] .

ex:bed_712          a s9:ChannelBed ; s9:layout "7.1.2" .

The same data as JSON-LD, which drops straight into an API response or a web page:

{
  "@context": { "s9": "https://spatial9.ai/ontology/spatial-audio#" },
  "@id": "https://catalog.example.com/vox_object",
  "@type": "s9:AudioObject",
  "s9:carries": { "@id": "https://catalog.example.com/song_0042_vocals" },
  "s9:width": 0.15,
  "s9:hasPosition": { "s9:azimuth": 0, "s9:elevation": 5, "s9:distance": 0.8 }
}

And a rule, written in SHACL, that rejects any object without exactly one position:

s9:AudioObjectShape a sh:NodeShape ;
    sh:targetClass s9:AudioObject ;
    sh:property [ sh:path s9:hasPosition ; sh:minCount 1 ; sh:maxCount 1 ;
                  sh:message "Every audio object needs exactly one position." ] .

Querying a catalog with Python

With the open source libraries rdflib and pySHACL you can load a catalog, validate it and ask questions in a few lines:

from rdflib import Graph
from pyshacl import validate

g = Graph()
g.parse("https://spatial9.ai/ontology/spatial-audio.ttl")   # vocabulary and rules
g.parse("catalog.ttl")                                      # your mixes

# 1. Run every rule. Each failure comes back with a plain-language message.
ok, _, report = validate(g, shacl_graph=g, inference="rdfs")
print("valid" if ok else report)

# 2. Which mixes have a lead vocal placed behind the listener? (azimuth beyond +/-90)
q = """
PREFIX s9: <https://spatial9.ai/ontology/spatial-audio#>
SELECT ?mix ?az WHERE {
  ?mix s9:presents/s9:hasElement ?obj .
  ?obj a s9:AudioObject ; s9:carries/s9:plays ?inst ; s9:hasPosition/s9:azimuth ?az .
  FILTER (CONTAINS(LCASE(STR(?inst)), "voice") && ABS(?az) > 90)
}"""
for mix, az in g.query(q):
    print(f"{mix}: lead vocal at {az} degrees, check with the mixer")

That second query is the kind of check that is impossible with a folder of files and trivial with a graph.

How Spatial9 applies the ontology

1. Recognise: from audio to individuals

When a stereo song arrives, Spatial9's Gravity AI separates it into stems and identifies what each stem plays. In ontology terms, it creates Stem individuals and links each to an Instrument. Because instruments sit in a SKOS tree (Voice, then Lead Voice; Percussion, then Kick), later stages can apply rules to a whole branch, such as "keep low percussion in the bed".

2. Place: from stems to spatial elements

Placement decides, for each stem, whether it becomes an Audio Object with a position and width, or part of a Channel Bed. The style you choose, such as live concert, club, cinema or intimate studio, is a set of placement defaults over instrument classes, not a hard-coded list of tracks. That is why a new instrument type gets a sensible place automatically.

3. Check: rules that protect the listener

Axioms and rules turn mixing experience into checks a machine can run: the low-frequency channel is never an object, lead vocals stay in front, very wide objects are flagged, elements in a presentation stay within loudness targets. They encode the same craft rules we describe in 10 non-negotiable best practices for immersive mixing and help avoid the listener fatigue covered in creative thinking in immersive mixing.

4. Render: one presentation, many formats

The renderer takes the mix presentation and writes each requested Format: Eclipsa Audio (IAMF) for streaming, a binaural WAV for headphones and a YouTube-ready MP4. Because the presentation is format-neutral, every output comes from the same decisions, so the headphone version and the speaker version cannot drift apart. See how formats relate in Eclipsa Audio vs MPEG-H 3D Audio and converting Dolby Atmos to Eclipsa Audio.

5. Expose: the same vocabulary for apps and agents

The Spatial9 MCP server, A2A agent and REST API speak in terms of the same concepts. A tool schema is a small ontology: create_spatial_audio takes an upload, a style and a title and produces a mix with formats; split_stems produces stems; get_downloads returns format individuals such as binaural, youtube_video and iamf. That consistency is what lets an AI agent plan a multi-step job without guessing, as shown in Spatial9 Agent Skills.

# Recording an MCP render as graph facts, so the catalog always knows what exists.
from rdflib import Graph, Namespace, URIRef, RDF, Literal

S9 = Namespace("https://spatial9.ai/ontology/spatial-audio#")
FORMATS = {"iamf": S9.IAMF, "binaural": S9.Binaural}            # ids returned by get_downloads

def record_render(g: Graph, track: str, job_id: str, downloads: list[dict]) -> None:
    mix = URIRef(f"https://catalog.example.com/{track}/mix/{job_id}")
    g.add((URIRef(f"https://catalog.example.com/{track}"), S9.hasMix, mix))
    renderer = URIRef(f"{mix}/renderer")
    g.add((mix, S9.presents, URIRef(f"{mix}/main")))
    g.add((URIRef(f"{mix}/main"), S9.renderedBy, renderer))
    for d in downloads:
        if d["id"] in FORMATS:                                   # ignore outputs we do not model
            g.add((renderer, S9.encodes, FORMATS[d["id"]]))
    g.add((mix, URIRef("http://purl.org/dc/terms/identifier"), Literal(job_id)))

Knowledge graphs for catalogs

Once every mix is a set of facts, a catalog becomes a knowledge graph, and questions that used to need a spreadsheet and a week become one query:

• Which albums have an Eclipsa Audio version but no binaural version?
• Which tracks use a 7.1.2 bed with more than 12 objects?
• Which mixes were rendered before a rule changed and should be checked again?
• Which catalogs contain solo piano, so we can apply the intimate studio style?

Enterprises often load the same facts into tables in Databricks or Snowflake; see Spatial9 for enterprise AI. The graph and the tables use the same names, so either can answer.

Common mistakes when modelling spatial audio

1. Using a file as the unit. A WAV file is a delivery, not a concept. Model the mix and its presentation, and let files be outputs of a renderer.
2. Mixing up objects and tracks. One track can feed several objects, and one object can carry several stems. Keep carries as its own relationship.
3. Storing positions without a convention. Always state the coordinate system. ADM uses azimuth positive to the left; some game engines use the opposite.
4. Forgetting the listener. Without Listener, Room and HRTF in the model you cannot explain why the binaural version sounds different from the speaker version.
5. Relying on OWL alone for quality control. OWL will happily infer that a missing position is unknown. Use SHACL for "must have".
6. Inventing everything. Align with ADM, IAMF and the Music Ontology first, then add only what is missing.

Frequently asked questions

What is an ontology in audio engineering?

An ontology in audio engineering is a formal, machine-readable model of the concepts in sound production, such as recordings, stems, instruments, mixes, channel beds, audio objects, renderers, formats and listeners, together with how they relate and the rules they must follow. It lets different tools and AI agents share the same meaning.

What is the difference between a channel bed, an audio object and an Ambisonic scene?

A channel bed is tied to fixed speaker positions, such as 7.1.2. An audio object is a sound with its own position, width and gain that a renderer places on any layout. An Ambisonic scene stores the whole sound field around a point and is decoded to any layout. One audio element is exactly one of these.

How does ADM relate to an audio ontology?

The Audio Definition Model, ITU-R BS.2076, is a detailed metadata model for immersive programmes. A spatial audio ontology aligns its classes, such as audio object and channel bed, with ADM types so ADM BWF files can be imported and exported without losing meaning.

Does IAMF have its own data model?

Yes. IAMF, the format behind Eclipsa Audio, organises sound into audio elements (channel based or scene based) and mix presentations that tell a player how to combine them. The Spatial9 ontology mirrors these two concepts directly.

How does Spatial9 use an ontology?

Spatial9 uses one shared model at every stage: Gravity AI labels separated stems as instruments, placement turns stems into audio objects or bed channels with positions, rules check the mix, the renderer writes each format, and the MCP server, A2A agent and API use the same vocabulary for apps and AI agents.

Can I download the Spatial9 spatial audio ontology?

Yes. Version 0.1 is a Turtle file at spatial9.ai/ontology/spatial-audio.ttl under the MIT licence. It includes the classes, properties and SHACL rules described in this guide.

Do I need RDF to benefit from this?

No. The same concepts work as database tables, JSON or column names in a data warehouse. RDF and OWL add precise meaning and easy linking with other music metadata, which is useful for large catalogs and AI agents.

Sources

1. ITU-R Recommendation BS.2076, Audio Definition Model.
2. Alliance for Open Media, Immersive Audio Model and Formats (IAMF) specification.
3. Raimond, Abdallah, Sandler and Giasson, "The Music Ontology", ISMIR 2007, and musicontology.com.
4. Fazekas and Sandler, "The Studio Ontology Framework", ISMIR 2011.
5. Ceriani and Fazekas, "Audio Commons Ontology", 2018.
6. AES69, AES standard for file exchange: spatial acoustic data file format (SOFA).
7. W3C Recommendations: RDF 1.1, OWL 2 Web Ontology Language, SKOS, SHACL and JSON-LD 1.1.
8. W3C Ontology for Media Resources 1.0.

Try Spatial9 free