A reasoning process that had its own form of representation that it could apply reliably to a class of problems would potentially save itself a great deal of repeated computation. If we could embed parts of our reasoning into a graph and embody them through compilation, we would save our reasoning and memory functionality a great deal of work.

1. Can all waveforms be meaningfully described in the same way, and can the information extracted be anything but tautological?

2. What does FeatureGraph lose by taking nothing into account about a signal other than its physical shape?

3. Why should these objects exist at all? What’s wrong with using peak detection and then calculating everything else afterwards?

4. What are you trying to represent with accumulation objects? What if the area between a signal and a boundary is physically meaningless? Aren’t you doing a lot of largely pointless computation?

(The easiest answer to number 4 is: you bought it, you paid for it, and we gave it to you. Accumulation is meaningful in some situations and not in others. If it’s not meaningful, we’re not going to use it. At the end of the process is the person who asked the question in the first place.)

Let’s start to discuss this precisely. We have a signal r. It’s the measured volume of a person’s lungs when they take a breath. The signal looks like this:

r1

r2

r3

r4

…

What do I see when I look at this signal? I see nothing, because to a human a list of numbers does not have queryable meaning. So I visualize the signal, and I see that it’s a wave. The subject inhales and exhales, and a sensor has recorded their breathing.

A wave is something I know about. Waves have peaks and troughs. They have amplitudes and periods. By visualizing the signal, by making it apparent to myself that it’s a wave, I can immediately point things out to you about this person’s breathing that I could not have looking at a list of numbers.

But that’s an advantage I have being human. If I were a computational layer instead of a human, I’d like to be able to see those waves and peaks and amplitudes and troughs as well. The way I do that is by deciding how I want to talk about what a wave is, what a peak is. A wave is a period of rising signal followed by falling signal. That’s a wave. We need two states to define it. Done.

I want to know two more things. When did I enter the rising state, and when did I leave it? Those are events. Events are things that happened once. States are things I enter and stay in. Once I know these four things, I can calculate everything else I need to know about this wave.

Among data practitioners, this is often an ad hoc individual process of a knowledgeable expert encoding relationships between parts of the data they already know well. Much of their work is not immediately applicable to similar problems or accessible to other experts with different views of the data available to them. If I cannot understand or recreate your code, I often cannot reproduce your work, and the conclusions you have reached can be frustratingly inaccessible to me.

As researchers we have a few options available to us. We can make the intermediate results of our analyses available to others. I can take your timeseries data and give you back a list of queryable aggregations, so that you never need to carry out that process yourself.

The primary complaint is that what disappears when an analysis is complete is much of the representation we would like to be able to recreate for that problem or similar problems. If you’ve already modeled a signal as a collection of states, boundaries, and behaviors, others might like to be able to use your representation of that signal without having to reproduce it. If you’ve already derived properties from the signal such as how much it’s physically accumulated over a time period, others might like a representation of those properties available to them.

Here’s an example. You approach me as a researcher. You have a signal, and you know more or less what the signal does. It repeats, it increases here and decreases there. When it enters state x, another signal enters state y.

You have questions like: how long was I in this state or that? How long did it take me to reach threshold a or value b? You don’t know, because all you have is data. So here we are.

In our study, we assume that the signal in composed of repeating states. In a wave, we already understand the mechanics of how the states repeat. In your data, you already know what the states are.

You can think of signals like this:

each signal is composed of repeating states

we can mark where we are in a state

we can mark when we enter or exit a state

For an object like a wave, I can tell you what the significant states are. For another type of signal or set of signals, you can define for me what the states you care about are. Then we can create a document that defines those states, tells you when you enter and exit those states, and then you’re done. You have states and events.

Once you have states and events, you move on to measures. Measures are when we talk about what happend over the course of an event. How high did the value go? How long does it take the signal to repeat? The key is that we now see the signal as an oscillation, a repeating wave.

So now you have more data. It’s like magic; you don’t know where it came from, but now you know how long you were in state a and how long it took to reach state b, and you know how that’s changed over the past month or year. And the best part is, we used the same ten lines of code to give you 90% of those results.