Your life in data: Is it all about events and properties?
January 7, 2011
I’m designing the data layer for my site, and it’s got me thinking about the essentials of what it is exactly that we track when self-experimenting. Putting on my ontologist‘s hat I’ve come up with two kinds of things that I think cover anything a human would want to track (I might as well be provocative here), and I’d love to get your feedback on how well it makes sense. I’m excited to ask the question here because, frankly, I’m not sure who else would understand it. Here goes.
It seems to me that all things measurable can be reduced to events and properties. (These are inspired by methods and attributes in object-oriented programming.) Events are things we do, like “ran 2-1/2 hours,” “took 81 mg of aspirin,” or “forced myself to laugh.” They answer the question about the past, “What did you do?”
Properties, on the other hand, capture some aspect of a thing at a particular moment, such as “the number of pimples on my face,” “my location,” or “whether it’s raining.” They answer the question about the present, “What is the state of the thing right now?” (An aside: If those two cover past and present, what role does the future play in this context? I wonder if it is theory, given its utility in prediction.)
Let me give you an example. I’m currently experimenting with ways to reduce tooth pain (I’m a grinder), and I’ve tested a number of possible causes so far – sugar, acidic foods, airflow, food temperature, and (as of this moment) daytime grinding. Each of these has events I care about: “ate ice cream,” “mountain biked,” and “inserted/removed night guard.” There’s only one corresponding property I’m tracking, “amount of pain in tooth 24.” Properties and events.
Another example is if you want to test the relationship between your happiness and sunny weather. In this case the event might be “exposed myself to sunshine,” and the property would be “my happiness.”
The reason this scheme seems reasonable to me is because of the nature of scientific inquiry. The way I think of how we experiment is that we: 1) think about some aspect of our lives we want to explore, 2) dream up something small we can change, 3) do it while collecting measurements, and then 4) analyze that data to decide what effects the changes had. Notice that there are two things at play in #3: Actions that I take (or things that happen around me), and measurements. Viola – events and properties!
Unfortunately, the word “measurements” in the last bit causes a problem. To me, measurement answers the question, “How much of it?”, and that applies to both events and properties. If we take the events in my bruxism experiment, what I want to know about them is a) how many hours I biked, and b) how many hours I wore the night guard before going to bed. Obviously I can measure these. For properties, what’s interesting is that, unlike in experiments, the measurements are intrinsic; all you can really do is ask how much of a property there is. (I haven’t nailed this down, but I think this dichotomy results from the existence of events being of value. That is, we’re primarily interested that they occurred at all. The quantity of them may or may not be useful. For example, I might not care how much I rode my bike, but simply whether I rode at all today.)
So there you have it. I’m really curious:
- What do you think of this analysis?
- Would typical self-experimenters (if there is such a person) get it?
- If you were designing an experiment, would thinking about measurements in this way help you?
- How do existing tools chop the world up? In particular I’m not sure I’ve seen properties explicitly identified. (Note: I’ve listed the multi-purpose tools I know about in my answer to What are some alternatives to Daytum?)
[Image from bartmaguire]
(Matt is a terminally-curious ex-NASA engineer and avid self-experimenter. His projects include developing the Think, Try, Learn philosophy, creating the Edison experimenter’s journal, and writing at his blog, The Experiment-Driven Life. Give him a holler at email@example.com)