The Sampling Ontology

Following the preliminary development steps we focused on creating a conceptual map to better distinguish and understand which classes, predicates, data, and object type properties were needed. Over the course of multiple conversations we discussed how deep the model should go and which key concepts were essential. At this stage we also made extensive reference to the MO, FRBR, and Audio Commons models.

The first thing to emerge from this process was a set of key conceptual elements that we knew were needed within our model and which formed a loop of sorts: the idea of a track, the idea of a Manifestation as defined by FRBR (the publication/production of an Expression), the idea of a sample, and the interactions between sample and track. This can be seen in figure 1.

We then refined the map, as seen in figure 2, by adding and linking concepts from MO, the Event Ontology, and foaf. We also expanded on the ways in which sample and track interacted with each other by taking inspiration from how WhoSampled models sampling relationships using musical elements, which are part of a track, and the different types of sample (direct or interpolation). We also decided to enhance the model by adding different types of manipulation, which impact the way the elements are transformed into a sample, as this felt like a key conceptual idea that is not represented in WhoSampled (at least in their public facing data).

Eventually we got to a point where we felt that it would be best to begin building the ontology as a way to stress test the validity of our conceptual map/model, in essence switching from our initial bottom-up approach to a top-down approach so that we could build the dataset based on the ontology. In doing this we realised that there was a potential issue in how we were reusing MO's classes and concepts as they related to the idea of sampling, which is at the heart of our ontology.

We debated whether the act of sampling should be considered as a sub-class of MO's composition, which clearly created some complications in how to link sampling to a track (see figure 2). This setup would also force us to reuse more of MO's framework which was clearly not designed for what we wanted to do. In the end, we decided to make sampling an event similar to how MO treats composition (using the Event Ontology) and make it a sub-class of MO's performance event class which is defined as an event "that might produce a sound" with input from agents and instruments. This was an ideal fit (see figure 4).

In turn, sampling was then linked to the Expression level via MO's existing properties for linking a performance to a signal, and then in turn we created two signal sub-classes (sample and elements) which formed the basis of what was needed for a sampling event (see figure 4). Lastly, these two sub-classes were linked to MO's track class, itself belonging to the Manifestation level. Therefore, we focused only on the Expression and Manifestation levels that MO borrows from FRBR and within those reused or created the necessary classes and properties to express the key conceptual elements we wanted (see figures 3 and 5).

With this structure in place we also borrowed the idea of a shortcut property from MO to allow the user two paths for connecting a song with the song that samples it: a long path that goes from Manifestation (source track) to Expression (elements of the source track) and then back to Manifesation (from elements to sample via manipulation, and from sample to new track); or a short path that links two tracks together using a simple self-referential property, samples/is_sampled_in. This was modelled on MO's records/recorded_as property, which we also reused in SamO as it bypasses the various steps in MO to directly link a signal to a performance, which in SamO links the act of sampling to the signals it creates (see figure 6).

After this we then debated whether or not the manipulation types should be considered as classes or properties. We tried both and ultimately properties proved best suited to the underlying conceptual idea that a manipulation allows the transformation of one class (elements) into another (sample), both of which belong to the parent class signal. This fits with MO's definition of a signal ("a master signal produced by a performance and a recording") and allowed us to maintain the needed connection between signal (Expression) and track (Manifestation). In the end, we settled on 10 different types of manipulation (sub-properties of manipulated_into/manipulation_of) that reflect some of the best known and standard practices such as looping, tuning, and scratching. It should be noted that ultimately a granular definition of how a sample was manipulated will always be a bit of a guessing game without direct input from the producer responsible for creating the sample. It's fair to assume that this is why WhoSampled does not indicate how samples have been manipulated, however we felt it was a worthy conceptual nuance to add to the ontology and that it may be useful to scholars and musicians alike should they want to detail exactly how tracks are transformed into samples.

As for the elements class, we originally imagined it to be a sub-class of MO's track however after defining the sampling event as detailed above we realised that it made most sense as a type of signal, especially as MO considers a track to be a compilation of signals. The different elements sub-classes were borrowed from WhoSampled and we decided to keep "lyric" and "voice" with the idea that the former can be used whenever there is an intelligible lyric being used in the sample while the latter works for any sonic element that uses a voice as its source but may not refer to a specific lyric or may transform an existing lyrics into a new one, as is the case in the song Oh Timbaland within our dataset (see figure 7).

From MO we reused the genre class, which allows the association of a track with a musical genre via the genre property, and also tried to express logical limitations for the track class by stating that it should have at least one genre and one element (see below for more on that). We also reused MO's instrument class and created a new sub-class for the sampler as an instrument with a further two sub-classes to differentiate between digital and analog samplers. The difference between the two is subtle, essentially axed on which interface it uses as noted in the description for each class, and they both have historical grounding however in reality the difference between digital and analogue samplers is quite fluid. Any digital sampler requires some sort of analogue element to be used and many analogue samplers will use some sort of digital processing. These two classes should also be most useful for connecting any dataset using SamO with other ontologies that deal with music.

Two last points. Firstly, we limited SamO in terms of data properties as these are not essential to the ontology. We ultimately carried over the duration property from MO to describe the lenght of tracks (and which could also be used to describe the length of samples if needed) and created a release_year property, for a song, for the needs of our Competency Questions (MO doesn't have an equivalently useful property). Secondly, we also discussed what happens when a sample becomes an element, which is the case for tracks that use samples, but decided that this should be left for future development as we found it difficult to create the necessary logical conditions in the ontology. In fact we hit similar issues when trying to define restrictions for some of our classes. For example, we wanted to be able to express the idea that the sampling event requires manipulation with a sampler; that any individual of the element class could only be part of maximum 1 track; that the sample class was part of some track; that a direct sample required at least 1 manipulated element; and that a track needed at least 1 genre and 1 element. Ultimately we defined these restrictions/conditions as equivalences using Manchester syntax in Protégé but aren't sure that this is the correct way to do it. Perhaps, we should just accept that there are limits to what an ontology can express.

• Bitches Brew -> Fattanza Blu (source)
• A Night In Tunisia -> Manifest (source)
• Fly Me To The Moon -> Splattitorium (source)
• Autumn Leaves -> Autumn Leaves (cover) (source)
• Caravan -> Jazzy Sensation (Jazzy Mix) (source)
• Cantaloupe Island -> Cantaloop (flip fantasia) (source)
• Skylark -> Survival of the Fittest (source)
• Mystic Brew -> Electric Relaxation + Mystic Bounce (source, source)
• Shadows -> It's a Jazz Thing (source)
• It Feels So Good -> Sticky Fingers (source)

• Django -> The Words (source)
• Just The Two of Us -> Just The Two of Us (source)
• So What -> Rimshot (intro) (Live) (source)
• Ain't Got No, I Got Life -> I've Got Life (source)
• Mr. Bojangles -> Jump Hi (source)
• I Want You -> Be Happy (source)
• Jungle Boogie -> The Doo-Bop Song (source)
• In A Silent Way -> Dopamina (source)
• Mister Magic -> Understanding (source)
• Aguas De Marco -> Girl From Alaska (source)
• Sinnerman -> Oh, Timbaland (source)
• Curtains -> Peng Black Girls (source)