[Orgmode] About TODO state, tags and properties in Org-mode

[Carsten Dominik]

         About TODO state, tags and properties in Org-mode

In a recent message to emacs-orgmode, Richard G Riley asked for
more background about the concept of properties and their
relation to tags.  Let me try to take a step back and explain
these concepts together.

Every node in an Org-mode outline tree is an /entry/.  Due to the
outline structure of the document, the entry may have a parent,
and it may have children.

In order to function as a task manager, Org-mode assigns certain
qualities to entries.  The most general way to assign qualities
are /properties/.  Properties are a list of keyword-value pairs.
In Org-mode, properties are stored in a special block, called the
/property drawer/.

In principle, the concept of properties would be enough to handle
everything that a user might want to assign to an item.  We could
have a "TodoState" property that captures the TODO state, a
"Priority" property that captures the priority, "Deadline",
"Scheduled", "Appointment" properties for dates and times, etc.

However, properties are a "heavy" concept.  Keeping them in a
plain text file requires a block of text under each and every
entry, making even simple lists complex and heavy, and hiding
important state information.  However, Org-mode was develloped
with the philosophy /Make simple things simple and hard things
possible/.  Therefore[1], Org-mode has other concepts the assign
qualities to entries by adding small strings to the entry line
itself.  These concepts are:

- The /TODO state/, a single word at the beginning of an entry
  line.  This can be viewed as a privileged property that can
  have exactly one of a limited number of values.  These values
  are mutually exclusive and the TODO state of an entry is
  uniquely determined.  Also, the TODO state cannot be inherited,
  i.e. it is independent of the states of the parent.

- The /priority/, indicated by a small cookie in the headline.
  Again, this could also be a property, but it is nice to have a
  way to use it in very simple lists.  Just like the TODO state,
  the priority is not inherited.

- /Tags/.  These can be viewed as /boolean/ properties.  They are
  either true of false, set or not-set.  Since TAGS are listed in
  the valuable real estate in the headline itself, they are
  always visible in in this way privileged.  Tags are inherited,
  i.e. if a parent has a certain tag, this tag also applies to
  its children (at least you can use them like this, but you can
  also localize tags fully to an entry by setting a variable).

So when should you use what?

- As a beginner, use just the TODO state and priorities.

- To categorize or to assign GTD contexts, use tags.

- Turn to properties if you need to assign a quality that has
  many values.  For example, when you find yourself creating tags
  like release_1_1, release_1_2, release_1_3, it is time to
  introduce your first property.

- Property are also used internally to store customization
  parameters that should apply to only a part of the outline
  tree, usually a subtree.  For example, the CATEGORY property
  defines the category of a (sub)tree.

I hope this makes things a bit clearer.

- Carsten

[1] OK, here I am lying.  This is not something that happened by
design, but historically.  First simple concepts like the TODO
states were implemented, tags and properties later.  However,
this is exactly why Org-mode still feels light-weight.  You
absolutely do not have to use the advanced concepts of tags and
properties if you only want a plain list or a TODO state.
Sometimes that fact that a piece of software has not been
designed top-down can work out in its advantage.