Before we begin, we must familiarize ourselves with the vocabulary “necessary”[note the quotation marks] for modelling. I have always believed that there is a fine line between vocabulary and jargon...and that line is necessity. One needs a vocabulary to describe the world...and jargon to appear poetic (read self-indulgent) about his description. Far too many people indulge in jargon while explaining; we will NOT.
Here is our vocabulary for modelling:
- Object: An Object is any observable item/thing/abstract entity in our world. For example, an alarm clock, a car, a batter in a baseball game are all objects.
- Event: An Event is an observation about how an Object works in our world. For example an alarm clock ringing, a car stopping at a traffic light, a batter hitting a home run are all examples of events. In essence, anything that falls within a cause-and-effect framework is an Event. An Event is often comprised of smaller Events on smaller Objects. The complexity of the Event is directly proportional to the number of sub-events chosen to model that event. Need an Event be as complex as possible? Absolutely not. The situation should determine how fine-grained our event should be and for the most part, the simpler the better.
- State: The condition or value of an Object during the timespan of the Event. For example, the timer in the alarm goes to 7:00am and this fires an internal signal that switched the buzzer from off to on. In this case, the global Object – alarm clock – has the state 'On', and the sub-objects – the timer and the buzzer – have the states '7:00am' and 'On' respectively.
Lets jump right in and create a [trivial] model. In this case, our Event is “Married Couple's date night”. This Event is easy enough to describe in plain English. If the husband, the wife and the babysitter are all free, the couple can have their date night while the babysitter takes care of their kids. If the husband, wife or babysitter are not free then tough noogies.
And [drum roll]....here's the model:
[Click graph to magnify]
Recall that we said a model can be a graphical approximation of an Event. All we have done here is created a pictorial representation of what we have described in plain English above. In scientific terms, this is called a Graph. The ardent reader is referred to Graph and Graph Theory for more information on the subject :
In this model, the global Object is an abstract entity - “date night” but is clearly observable and hence qualifies to be modelled as an Event. The States of the global Object are 'Bummer' and 'Oh Yeah'. The sub-objects are the husband's schedule, the wife's schedule and the babysitters schedule, all of which are abstract objects. Each of the objects has 2 states associated with them – 'Yes' and 'No'. From the diagram we observe that for the state 'Oh Yeah!' to be activated, all three sub-objects must be in the 'Yes' state. Otherwise, the 'Bummer' event is activated.
Note that for every graph, there is a corresponding mathematical/algorithmic model, and that is simply stating the graph as a function:
result = 'Oh Yeah!' iff (isHusbandFree='Yes' AND isWifeFree='Yes')
AND isBabySitterFree='Yes'
= 'Bummer' otherwise
Again, the ardent reader is referred to Boolean Algebra for more information.
Now lets imagine a more complex event – identifying a song, based on the first 5 seconds of a music clip. How would one graphically [or mathematically or algorithmically] model such an Event? How simple or complex does the model have to be to reasonably capture the phenomenon?
These questions form the foundation of Information Processing in Music, and we will explore them in subsequent articles. Stay tuned.
