Although the article may not have made it clear, OSC is designed primarily to pass around <i>control signals</i>, rather than arbitrary, <i>non-contextualized</i> data. Control signals have inherent meaning, like &quot;fast-forward &lt;n&gt; seconds&quot;, &quot;set color to &lt;x&gt;&quot;, etc. The important distinction is that &quot;set color to &lt;x&gt;&quot; (a command) is distinct from &quot;{ &#x27;color&#x27;: &#x27;x&#x27;}&quot; (non-contextualized data).<p>The layout of <i>controls</i> is hierarchical in the protocol; each control has an associated endpoint, which looks very much like a unix file path. For example, to unpause an audio player, you would send the message &quot;&#x2F;player&#x2F;is_playing&#x2F;set t&quot; (or f, to pause). If you wanted to control the bands of a 10-band equalizer, you could implement that as &quot;&#x2F;player&#x2F;eq&#x2F;band&#x2F;4&#x2F;amp&#x2F;set 0.5&quot; (there are certainly other ways to approach it too).<p>If you want to send control signals to multiple parts of the audio player at the same time, you could use a &quot;bundle&quot; composed of a separate message for each parameter you&#x27;re altering. All the messages will then be handled simultaneously.<p>Because of this, data does not need to be hierarchical. If you <i>really</i> want to, you can consider the endpoints to be &quot;keys&quot; and the control data to be &quot;values&quot; in a hierachical key -&gt; value map, just to prove that everything you could do with hierarchical data is still possible using OSC. But I would encourage you to not think of it in that abstraction because the fact that OSC is built to pass messages, and not non-contextualized data is a large part of what differentiates it from other protocols like json streaming.