Today, I came across this blog post by Seth Ladd, which has actually nothing to do with ontology design, but with a RESTful way of designing an account activation system. Anyway, the last paragraph of it says:

In summary, I love working with REST because it forces me to think in nouns, which are classes. I find it easier to model the world with nouns than with verbs. Plus, the problem with verbs is you can’t say anything about them, so you lose the ability to add metadata to the events in the system.

This particular sentence reminded me of a lot of discussion on the MO mailing list, which happened when we started looking towards the description of the music production workflow (an idea coming from the older Music Production Ontology) and the Event ontology as a foundation for it. Indeed, the ontology started with only a small number of concepts (well, basically, only the 4 standard FRBR terms), but with many relationships trying to cover a wide range: from this expression is in fact an arrangement of this work to this person is playing this instrument. But, once you want to be more expressive, you are stuck. For example, you can't express things such as this person is playing this instrument in this particular performance anymore---you can't say anything about verbs (unless you go into RDF reification, but, well, who really wants to go into it? :-) ).

workflow-top.png

When you start talking about a workflow of interconnected events (composition/arrangement/performance/recording, for example), you limit the number of relationships you have to provide (ultimately, relations between things are all held by an event - so you just need the five relationships defined in the Event ontology) in favor of some event concepts and some concepts covering your objects (musical work, score, signal, etc.). Now, you can actually attach any information you want to any of these events, allowing a large number of possible extensions to be built on top of your ontology. For example, we can refer to a custom recording device taxonomy by just stating something like ex:myrecording event:factor ex:shureSM58.

Moreover, the Event ontology also provides a way to break down events, so you can even break complex events (such as a group performance) into simpler events (a particular performer playing a particular instrument at a particular time).

(Actually, there are lots of papers on this sort of subject, like these ones on the ABC/Harmony project, this one on token reification in temporal reasoning or this one on modularisation of domain ontologies.)