From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: Adding tags, grouping tags Date: Mon, 25 Oct 2010 08:18:45 +0200 Message-ID: <568820C3-2479-4264-85DA-70DD531E0577@gmail.com> References: <4CC2FC16.9050202@alum.mit.edu> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=56788 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAI65-00041n-CD for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:08:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAI63-0003px-KH for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:08:00 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:56015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAI63-0003pt-BG for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:07:59 -0400 Received: by ewy25 with SMTP id 25so1443443ewy.0 for ; Mon, 25 Oct 2010 01:07:58 -0700 (PDT) In-Reply-To: <4CC2FC16.9050202@alum.mit.edu> 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: rjhorn@alum.mit.edu Cc: emacs-orgmode@gnu.org Hi, I have the feeling that there are really two strands of discussion going on here. 1. A two-level or even hierarchical way to *enter* *normal* tags, i.e. tags that are specified in the headline of a node. 2. A complex new structure that would somehow utilize properties to crease a tag-like parallel structure that can be used in searches. Is this a correct view of what is being discussed? - Carsten On Oct 23, 2010, at 5:15 PM, Robert Horn wrote: > 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 > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode