From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Horn Subject: Re: Re: Adding tags, grouping tags Date: Sat, 23 Oct 2010 11:15:34 -0400 Message-ID: <4CC2FC16.9050202@alum.mit.edu> Reply-To: rjhorn@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=46946 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9foU-00063k-Eo for emacs-orgmode@gnu.org; Sat, 23 Oct 2010 11:15:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9foS-0005dV-V4 for emacs-orgmode@gnu.org; Sat, 23 Oct 2010 11:15:18 -0400 Received: from mail2.panix.com ([166.84.1.73]:51326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9foS-0005d9-Sr for emacs-orgmode@gnu.org; Sat, 23 Oct 2010 11:15:16 -0400 Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail2.panix.com (Postfix) with ESMTP id A7C9738E4E for ; Sat, 23 Oct 2010 11:15:15 -0400 (EDT) Received: from [192.168.1.21] (panix2.panix.com [166.84.1.2]) by mailbackend.panix.com (Postfix) with ESMTP id 897B5328C6 for ; Sat, 23 Oct 2010 11:15:15 -0400 (EDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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 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