I'm a data analyst by trade, and I thought I'd share some of my thoughts so far. You've prolly got a "too long" to-do list already, but I LOVE what you're doing with this and maybe this'll help in some roundabout way.
First, from a user perspective, having to click the "edit" button to see the tags seems like extra work. Maybe tags should be visible for each line-item. I think this is the case because tags were implemented after the action log UI was created.
Also, I'm not entirely sure what tags are for. I tag a lot of things with "health," but I'll click on a "weight" observation and at the next screen there is only a "health (1)" instead of "health (# of items tagged with health)". Honestly, I was expecting the tagging to be on the same structural level with the title of the field, like "weight." Now that I have 2 weight observations, it shows up as "health (2)," so it looks like it's a tree-structure of some sort. This works well for something like "watched," so you can see how many "watched"s were #movies, and how many were #tv, or #jtv etc., but not exactly what I was expecting. Maybe there's an explanation for this that I'm missing.
What I was expecting would require more storage space than it looks like your data uses now. Essentially, (in retrospect) I was expecting that there only be tags, and not really an action name (the action would be a tag as well). The primary entry of concern would be the value, and tags would be attached to that value. However, each tag on a certain value might demand a different data type. So I could have something like this:
Value: 97
Units: minutes
Time: 01-31-10 16:27:34
Tags: watched(m), movie(cnt), rating(cat), moviepremier(e)
So, each tag is like it's own field, and can be used as a tag to sort, group, etc. data with much more flexibility. Of course, this uses much more hd space (4x+ more in this case, it would seem). So: watched(m) = 97; movie(cnt) = 1; etc. This isn't a perfect example, but I was hoping to get my thoughts across. It would seem that multiple values may be needed for each (cat) tag, and I haven't really figured out what event tags are for(???). More flexible, but more complicated programatically. A structure like this would open the doors to a LOT of customization with regards to building visualizations.
I almost want to say this is like OLAP, but I'm not familiar enough with what OLAP is to make that assertion. Maybe that rings some bell.
What's the intuition for using that type? I've got it for "gnight" and "gmorning", but I've got values in there also representing my time awake and time asleep. Which brings up another thought. Considering the pairing you do in the duration viz, It would seem useful to pair items, so that when I log "gmorning," the duration between "gnight" and "gmorning" is logged. And similarly with "gnight" (waking hours). This could just as easily be logged as a new variable like "sleep" or "awake," or as I do... I just fill in the value for "gnight" with the sleep duration, to keep the number of fields down. Another thought I guess.
I absolutely LOVE this project and am glad I found you. I subsequently found daytum.com, and what you're doing has much more potential - daytum seems like a glorified counter... you can't even track your weight! ... or I couldn't figure out how to (could sort of hack it if necessary). I'm looking at grafitter.com also, but that certainly looks limited compared to what you've got here.
KEEP UP THE GREAT WORK!
Dan
PS I'm going to track the foods I eat (as counter types) and create a dataset on my own comp with the nutrition facts. So, when I export that data from yfd, I'll merge it with the nutrition facts and have a-whole-nother world of personal data to explore on my own. That seems like some functionality that could be added later on, but to much work to generalize for the site now.
btw, if you like to read fiction, check out BookLamp.org. That's my Data Analyst job. flowingdata.com has inspired some very interesting ideas that I'm gonna go explore at the office right now. So, thanks again. ... and sorry for the lengthy post. : \