Metadata and Taxonomies (aka How do I find it my way?)

Some of the very best PIMs allow you to organize your data according to your needs. Usually that involves using tags or categories. And a great deal of discussion has gone into whether tagging or categorization is more effective for people who are tracking large amounts of information.

What is the difference? Tagging is like sewing little labels on your socks, categorizing is like picking the specific drawer to pick each type of sock in. I would suggest that the best overview document is Shirkey's document here. He very effectively details the strengths and weaknesses of both methods. I would also suggest Christian Ricci's discussion for very clean examples of solid uses of Taxonomies.

After reading Shirkey's notes you may be left with the idea that Tags are the "One True and Useful Way". To the extent that he talks about (i.e. the world of the web) that may be very true. But in the world of PIM the many weaknesses of Taxonomies become strengths for an individual user. The first person I found that seems to have firmly grasped that is Paul Chen here. And so what I am aiming for is the use of Taxonomies where the user finds it works for them and tags as necessary.

For now I want to talk about Taxonomies (I will expand on tags in another post). First are some definitions. A Taxonomy is a representation of concepts (called Taxa) that have distinct relationships.

For example a Taxonomy of the communities I track in my PIM would have Work, Church, Family, and Friends. Friends would have a distinct subset of "College Friends" and Family would have related subsets for each family grouping for my immediate family, my wife's family and my ex-wife's family (see graphic above).

A taxonomy encodes the relationships between the concepts. These include:

• is-a-type-of relationships like spaghetti is-a-type-of pasta.
• is-an-instance-of-a relationship like "my spaghetti dinner" is-an-instance-of-a "spaghetti dinner".
• is-part-of relationship like Rome is-a-part-of Italy.
• is-associated-with relationship like Spaghetti is-associated-with Italy.

These relationships could be the key to achieving smooth access to the information you need when you need it. For example, if I had a tree of communities associated with each other such as the picture above then when I went to reply to an email from my brother I could quickly be given the oppurtunity to email it to my immediate family or the next highest group up beyond that. If a PIM supported multiple user defined Taxonomies such as a Community Taxonomy or a Calendar Taxonomy then the user could view each level of the taxonomy using the views that made sense for them.

As an example, a taxonomy could have the following levels and relationships Calendar->Jim, Janice, Boys, Church, Work with additional subgroupings of Church->Board of Trustees, Worship Committee. Any type of object could be associated with any level such as Work but only those objects that have an Aspect of LIT would show up in a calendar view or a schedule view. Only those objects with the aspect of LIS would show up in a map view.

Of course, as a user my preference would be for being able to create and manipulate taxonomies quickly as well as associate searches with Taxa for the ability to create flexible taxonomies.

Tailoring the domain model.

In the previous post I stated that I believe the path to a usable PIM lies in allowing the user to tailor the domain model to match how they work. That is a great ideal and very laudable but the world is afloat with software that is so tailorable that it is unusable. How to manage this so that the user is not overwhelmed, annoyed or just plain pissed of is going to take some thought. So the first thing to look at is at what will not vary.

There are some things that I believe form the foundation of the things to be managed in a PIM:

• Events: Things that happen
• Actions: Thing that are done or performed.
• Notes: Things that are recorded for later.
• Contacts: Info on people.

And, after looking at the model for awhile I believe that there are some "aspects" or "potential behaviors" that can be associated with each object. The aspects that I can see immediately are:]

Can be Located in Time abbreviated LIT
We can place this on some sort of chronology (Calendar, Schedule, etc)

Can occupy time abbreviated OT
We can view its duration. This may be a logical part of the LIT aspect above

Can be Located in Space abbreviated LIS
We can place this on some sort of map

Can be tracked abbreviated TRK
We can track its progress

Can have a lifespan abbreviated SPN
We can see the object become relevant and expire.

Much of what determines what is visible in a given context is the aspects associated with the object. And those aspects can be applied or not as necessary. The Chandler project refers to this as "Stamping". For example an Event may be made "mappable" by stamping it as LIS. The user may choose to leave its location indeterminate but it is the stamping of the object as LIS that makes it mappable, not that it is given a location. With these building blocks the user has the potential to create many specialized types as needed. i.e. a Promise could be an Action that can be tracked and has a limited lifespan. In addition, the user can then display a Calendar which contains all things that are LIT whether they be Notes about an Event, an Event or a Promise.

Of course most users will want to filter things down to what they want. But then, now that we have determined what governs what CAN be displayed we come to looking at how we filter things down narrower then the aspects associated with the objects. And for that we need to look at the thing that PIMs are expected to handle well. And that is metadata; taxonomies, tags and categories. Since that is a substantial topic in and of itself, that will be covered in a seperate post.

"You keep using that word. I do not think it means what you think it means."

In my previous post I talked about how often users adapt to the PIM rather than the reverse. And no matter how intelligent the developers are the end result of their designs often seems to come up with eerily similar results (Chandler and Ecco being a somewhat notable exceptions). Most PIMs seem to end up with some variation on Tasks, a Todo List, one or more calendars, some events and some categories....

But the domain that we are all trying to model doesn't seem to be that clean cut. When I started out modeling the domain I discovered that very little appears to be set in stone. Most clear statements I can make about the domain are of the "may" or "can" type.

Here are some of the objects that I believe need to be modeled (in no particular ordering):

Events, Meetings, Appointments, Promises, Tasks, Birthdays, Anniversaries, People, Organizations, Checklists, Todo lists, Schedules, Calendars, Communities, Projects, Conversations, Goals, Journals, Directions, Notes and references to resources.

And here are some example statements I can make about some of these objects:

• Events may be located in time.
• Events may occupy time.
• Events probably will be located in space (have a location)
• Events may have participants
• Events may have an owner

• Actions may have an owner
• Actions may be located in time.
• Actions may occupy time.
• Actions may have a location.
• Actions may have participants.

For almost every object in the domain there is some ambiguity about what its behaviors and attributes are. The ambiguity seems to come from several areas. Some of it comes from the context you are working in at the time: the "Honey-Do" list at home may be managed and tracked differently than the project todo list at work. Some ambiguity comes from the fuzziness of the words themselves: What is the difference between a Task that is scheduled in time and an Event? And some of the ambiguity comes from the precision the user expects from the word itself: One user may consider Tasks very important objects to be managed in priority order with due dates and other users may expect Tasks to be simple entries in a list that you mark off when you are done.

So it seems inevitable that there will be significant mismatches between the model that a PIM uses and the worldview of the user. I think the key thing I see here is that the PIM's domain model needs to be tailorable to match the user's world view.

Where is flexibility needed ?

People have been very generous with their time and talking about how they manage the details of their life using a PIM or equivalent. I have been astounded with how people have adapted to the PIM of their choice.

And that seems to be the theme. Anyone who is using an electronic PIM seems to have done some significant adaptation to the PIM itself. It may be simply accepting that you can only have 15 categories for all Tasks, Events and so on. It may also involve managing things in multiple applications and sharing data between them.

Some of the issues people have adapted to:

• PIMs that have only one calendar.
• PIMs that require you to share the same set of categories among events, contacts, and tasks.
• PIMs that only allow you to set one category for each contact.
• PIMs that assume tasks can only have a due date. If you want to reserve a time for doing it the user needs to schedule it seperately as an event.
• PIMs that don't allow you to schedule an event until everything is known. When and how long , etc..
• PIMs that make it difficult to move the information in and out.
• PIMs that only allow you to track the members of an organization, not the organization itself.

I could go on but the basic idea seems to be that the limitations appear to be arbitrary and sometimes they appear counter intuitive. Yet it seems unlikely to me that everyone involved in the development of a PIM is making arbitrary decisions for the fun of it. There are some very smart people working in this space. Just look at the teams working on Chandler, the KDE PIM or Evolution.

As far as I can tell the issue seems to be how the PIMs choose to manage complexity. All PIMs atempt to manage complexity for the user. Many of them do so by making assumptions about what a user needs.

The tension is between making managing the complexity that gets presented to the user and making the underpinnings flexible enough to support the whole range of activities.