Intentional Objects and Relationship Objects

I’m beginning to think about how to conceptualize the world of personal information management, and I’m finding some food for thought.

First of all, I was quite interested in a Viewpoint by Yoav Shoham in Communications of the ACM (not sure if non-members can read it, but the link is here).

Yoav and two co-founders started Timeful, a PIM company sold to Google in 2015.  His Viewpoint was about Timeful’s approach to generalizing time events.

What they zeroed in on was the intentional aspect of calendar events.  A meeting, a habit, a bucket-list entry, all have a time and calendar element, but they vary in other aspects, including their relationship to our intentions.  Timeful reified these as “Intentional Objects” or IO’s, which were the foundation of the Timeful design.

Sadly, all one can see of this design is a screenshot or two from Yoav’s papers, because Google, after it acquired Timeful, shut down its app and threw the cloak of secrecy over how the work would be developed within the ‘Plex.  Their right to do so, of course, but something of a pathetic move for a company with their stature and cash flow.

Timeful, I’m surmising, used the various aspects of an IO to plan automated scheduling for all of one’s time-based events: the weekly status meeting, the visit to the gym, the daily block of work on the Great American Novel.  A very interesting line of thinking, and an interesting app (although I must say my tastes run more to Intelligent Assistants than to Omniscient AIs: I would rather have the app perform as an amanuensis than as an opaque oracle, but maybe that’s what the Timeful team had in mind, or maybe that’s what Google has in mind.)

In any case, I started thinking about contacts in the same way that the Timeful team was thinking about calendar entries: think outside the box, try to generalize, try to see what human purposes are being served by maintaining a contact list.

A couple of reflections:

  1. I have contacts in my contact list where I’m interested in the individual, where I’m interested in the couple, and where I’m interested in the household (e.g., neighbors).  Why do we have to treat these all the same way in a contact list, and how do we design a “Relationship Object” that will  capture the nuances of these differences and allow our software to work expressively with them.
  2. There are lots of non-humans that want me to treat them like humans.  In particular, corporations and brands want me to Like them, to white-list them, and to store them as contacts just like my individuals, couples, and households.  Are these really the same thing?  Why not?  Is it because of the asymmetry in our relationship (they can yammer at me; I can’t really yammer at them, for example), or is it because of the power asymmetry?  Is there a power dimension to all contacts?  How to model that?
  3. How about contacts that can order me around (IRS) or even kill me (Selective Service, for those of us who remember the draft)?  How do we model that?  Do their “requests” (demands, really) have more urgency than others’?  More importance?

Love your thoughts on all this, and on how IO’s and RO’s and <other>O’s would interact in the PIM of tomorrow…

2 thoughts on “Intentional Objects and Relationship Objects”

  1. Maybe we’re missing a “relationship object.” But maybe we need a new attribute of the “contact object” we’ve already got, which assumes the contact is an individual. For example, the contact could be a person, place or thing. Then we could add hierarchy; for example there could be a “group” person, place or thing, which is a parent of other groups or singletons. That would enable you to have a group for relatives, which is a parent of all relative households, which is a parent of the individual people in that household. For searching and indexing purposes, they’d all be the same, but groups would have lists of links to the entities contained in them.

  2. For things that aren’t people, maybe they need to be modeled as different entities. (It’s so annoying that my conference call number -entity?- has to be modeled as person; people don’t have host and participant numbers, for instance).

    But a lot of these things we might call attributes of thing or classes of thing are instead just set membership. Actually, I think google plus sort of gets this part right. Sorting people into friends, family, colleagues, acquaintances, and Gasp!, allowing someone to be part of many sets.

Comments are closed.