Your life in data: Is it all about events and properties?

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 matt@matthewcornell.org)

About Matthew Cornell

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 matt@matthewcornell.org
This entry was posted in Discussions and tagged , . Bookmark the permalink.

10 Responses to Your life in data: Is it all about events and properties?

  1. Pingback: Tweets that mention Your life in data: Is it all about events and properties? | Quantified Self -- Topsy.com

  2. Cindy says:

    To answer your questions in order:
    1. I think the events and properties approach proposed above misses out on the opportunity to take advantage of a lot of existing experimental design and process control methods. Why not stand on the shoulders of giants? See for example:
    http://statistics.laerd.com/statistical-guides/types-of-variable.php ** By following established ways of manipulating variables (defining, collecting, storing, extracting, analyzing) you can spend your time learning what you want to learn and use it to improve y|our li(fe|ves).
    2. I don’t know if I’m typical but, no, I don’t get inventing a new technique when existing techniques work.
    3. No. This technique would not be helpful. I want to follow the analysis “cook books” out there to use my data.
    4. Not sure if sufficient, open tools exist. Defining, using and maintaining an accurate, “easier-to-use-right-than-use-wrong” database is the hardest part of this whole experimentation and control environment. Maybe consider some of the stuff from here: http://www.amazon.com/Data-Analysis-Open-Source-Tools/dp/0596802358/ref=ntt_at_ep_dpi_1 Maybe there is some stuff in SourceForge?

  3. Cindy says:

    This didn’t get included in my comment above:

    ** Not saying this website (laerd.com) is a giant. Just giving an example of existing methods which this website happens to show clearly and concisely.

  4. Jeremy says:

    Matt, have you looked into EAV models used in clinical data systems? They have similar challenges in making adequately general schema for all the different kinds of data being recorded.

    Cindy, I think Matt is working on a bigger picture problem than what’s addressed by the experimental design page you link to. He’s building one schema to accomodate arbitrary experimental designs.

  5. Matthew Cornell says:

    Hi Cindy,

    Thanks very much for your comment. I think my post wasn’t clear – I was exploring the particular idea of thinking about what we measure from this events/properties perspective, not going into the underlying data model in any detail. For the latter, after pounding on lots of possibilities including events/properties and “counts” I decided to start with the dead simple minimum for defining a measurement: Name, data type (‘number’ or ‘list’), units (optional), and description (optional). There’s an implicit date-time stamp for each one, of course. This lines up exactly with the statistical types your link talks about – Categorical and Continuous Variables. Deciding dependent and independent variables is up to the experiment’s designer. Interestingly, this approach is very much like Jeremy’s EAV model.

    Thanks also for your feedback on the events/properties model not being helpful to you. That’s good data. I’ll check out Janert’s book – much appreciated. I’m talking with Seth Roberts about the scientific analysis side of things, so perfect timing, that.

  6. Matthew Cornell says:

    Jeremy – thanks a ton for your EAV pointer. It looks a lot like what I’ve cooked up. A quick scan of http://en.wikipedia.org/wiki/Entity-attribute-value_model brought up some good issues. In the Edison case, there are differences, such as:

    > For clinical findings, the entity is the /patient event/

    Aha! This is what I was getting at with the events/properties idea. There are particular events in our lives that we think could be meaningful to our experiment’s goal, and these would be the entities in the EAV model – similar to the patient event above, e.g.,

    ( , , “2.5″ )

    However, at other times the entities are things with attributes (I’ll drop the name “properties”), e.g.,

    ( , , “5″ )

    How about weather?

    ( , , “cloudy” )

    Those last two start getting weird – only a programmer would think “pimples is a property of my face,” right?

    Going back to my post, you can see that the events/properties scheme would naturally be implemented /on top of/ in an EAV system. But the key was whether looking at the self-tracking world that way would gave some guidance and structure to people who are using my system. I still haven’t decided.

    Lots more to think about. Thanks again for the pointer, Jeremy.

  7. Mark says:

    I think the properties/events monikers would only be useful to programmers.

    For everyone else, it might be simpler to use terms already understood and associated with the idea those terms are attempting to capture. That would be ‘behaviour’ for ‘events’, and ‘attributes’ for ‘properties’.

    There are also other meaningful categories. One is the concept of a ‘trait’. A trait can be an attribute, e.g. height, but it can also be a psychological trait, e.g. extraversion. The latter are constructs which can be measured in different ways; through behaviour (e.g., frequency of attending social events), or approximated via physiological data (e.g., heartrate in response to socialising). So technically a psychological trait is an attribute, but it’s measured either through other attributes or through behaviour.

    Finally, there’s another class of things that can be measured; things that happen to you. I think that’s a more appropriate use of the term ‘event’. Generally the things we’re interested in are things we have meaningful control over, so they can be expressed in terms of exercising that control (i.e., behaviour). However, there might be some circumstances in which exercising control is difficult, if not impossible. E.g. to reduce migraines you can avoid certain triggers. One might be loud noise. While it’s possible to avoid loud noises in most situations, if you’re out and about in a city you’re inevitably exposed to many sources of loud noise. So while you might measure your attempt at minimising noise (e.g., ‘wore earplugs’), it would still be important to capture the triggering event itself (e.g., ‘car backfired’).

    On the other hand, there is at least one way of describing events as behaviours; as passive behaviours, i.e., in terms of how we sense the event. So the event:’car backfired’ example could become passive-behaviour:’heard car backfire’. The latter might be more useful because it may help make ways of exercising control more obvious.

    • Matthew Cornell says:

      Excellent comments, Mark. I’m really glad you understood the concept I was trying to get across.

      > For everyone else .. ‘behaviour’ for ‘events’, and ‘attributes’ for ‘properties’

      Good suggestions. My concern with ‘behavior’ is that it implies to me a biological (or other) agent. Is ‘it rained’ a behavior? Hmm!

      > A trait can be an attribute, e.g. height, but it can also be a psychological trait, e.g. extraversion. The latter are constructs which can be measured in different ways; through behaviour (e.g., frequency of attending social events), or approximated via physiological data (e.g., heartrate in response to socialising). So technically a psychological trait is an attribute, but it’s measured either through other attributes or through behaviour.

      That’s really interesting. Breaking down attributes according to how they’re measured is useful. Thanks!

      > things that happen to you

      I see what you’re getting at. I used ‘event’ to mean any activity – self-initiated or otherwise – that can happen. Again, like your point about traits, it might be helpful to separate out subtypes, per your discussion of assessing, and making explicit, who is in control, or not – in healthy ways, as you point out below.

      > describing events as behaviours; as passive behaviours, i.e., in terms of how we sense the event. So the event:’car backfired’ example could become passive-behaviour:’heard car backfire’. The latter might be more useful because it may help make ways of exercising control more obvious.

      Yes, I had wondered this myself. It goes to whether measuring is itself an event. I think there’s some subtle decisions that a self-experimenter has to make when setting up something like this, and it’s not necessarily straightforward. In Edison ( http://edison.thinktrylearn.com/ ) I’m planning on a wizard to help new users, and incorporating behaviors and attributes is one way I thought to structure the guidance.

      Thanks a ton, Mark.

  8. Cindy says:

    Yes, the EAV link is quite useful to understanding what you’re trying to construct. If I understand it correctly, you’re trying to devise a way to store values for an experimenter to use in managing their experiment. There needs to be enough flexibility to allow many different hypotheses to be explored. Part of it is how to coach the user for the correct input to the appropriate field. Yes?

    Would it follow that the other part of what you’re trying to construct is a system that would take data fields and apply appropriate analysis methods to produce an output? I’m trying to understand the part of what will be done with the data once it is appropriately input.

    • Matthew Cornell says:

      For your first point (defining and capturing data), yes, I need a flexible format that allows experimenters to save data for any kind of experiment. Since this involves subtleties and important decisions, I will definitely need to provide some guidance/coaching on how to define experiments, especially what measurements they’ll make.

      On your second point (analyzing data), I want exactly what you describe: An AI program that will make sense of any data you throw at it. I’m told that is not possible given the state of the art, but certainly providing some rudimentary statistical visualization tools to start.

      Thanks for commenting!

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.