Re: Re: Adding tags, grouping tags

[Robert Horn <rjhorn@alum.mit.edu>]

On 10/16/10 4:09 PM, Carsten Dominik wrote:
>
> On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:
>
>> On 10/16/2010 01:32 AM, Carsten Dominik wrote:
>>>
>>> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
>>>
>>>> Karl Maihofer <ignoramus <at> gmx.de> writes:
>>>>> Besides that I have tags in other contexts, e.g. GTD-related tags etc.
>>>>> So it would be very useful to be able to group the tags as it is
>>>>> possible for agenda commands.
>>>>
>>>> I think that a way to define logical groups of tags (or even a
>>>> hierarchy of tags
>>>> -- say with a subtree of tag names?) would be a very useful addition.
>>>
>>> I can see that this could be useful - but the code is
>>> not in any way prepared to do this, so this would be pretty hard
>>> to implement.
>>>
>> Is it worth exploring use of the properties drawer? The tags in org are
>> a fairly simple and thus limited structure. The properties drawer can
>> have a lot more structure with a more controlled environment.
>
> I don't think I understand what you mean here. How would that help?
>
> - Carsten

My first thought was just to deal with visual clutter and parsing
headaches. Encoding standards like IDv3 have a large list of tags and
tags with values that are encoded and hidden in MP3 files. The display
is controlled by application. This is very much like the drawer
behavior in org. So putting tags into drawers would deal with the
clutter associated with having a great many tags on one item.

The next level would be to have org aware of the tag structure. This
would mean having a vocabulary description that describes the tags.
The vocabulary can be described as:

Top level: Context, e.g., GTD
   Level 1: TagA
     Level 2: TagB, a kind of TagA
        Level 3: TagC, a kind of TagB
   Level 1: TagD
   etc

Usually Tags are unique with in a context, but might collide between
contexts. So I might find the tag "TASK" used in different contexts.
Multiple tags can occur within a context, so something might have TagA
and TagD, and the presence of a lower level tag implies the higher level
tags. So TagC would imply TagB and TagA in the example above.

This is a simplification of full ontological structures that can be
expressed in a language like OWL, but it is one that people can grasp
and use easily. It meets most needs. The music and photographic
standards and their easy usage indicates this.

The vocabulary description could easily be done with some lisp
customization, the way it is done for task states, or it could be in an
org file. Both ways have their advantages.

For each tag you can have a list of pairs of context+tag to keep tags
unique. Appending these as text to each line introduces a lot of visual
clutter and parsing headaches. I would put these into drawers to reduce
the visual clutter and manage duplication. For the tag descriptions I
would have another location that has the full structure of tags, so that
a friendly display selection could be used that reflects the hierarchy.
A tag assignment similar to the IDO selection of levels within an org
hierarchy would make sense. Perhaps an org structure would make sense
for the vocabulary.

A simpler tag that means "look in the tags drawer" would keep the text
file readable and let the agenda processing deal with extracting and
displaying. Non agenda views of the org file would just have the "look
in tags drawer" tag. The viewing options would need to recognize this to
control how the drawer tags are displayed.

R Horn