From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Moe Subject: Re: Re: Adding tags, grouping tags Date: Sun, 24 Oct 2010 16:06:09 +0200 Message-ID: <4CC43D51.2000907@christianmoe.com> References: <4CC2FC16.9050202@alum.mit.edu> Reply-To: mail@christianmoe.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=53987 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PA1C4-0000lx-88 for emacs-orgmode@gnu.org; Sun, 24 Oct 2010 10:05:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PA1C2-0005xT-Br for emacs-orgmode@gnu.org; Sun, 24 Oct 2010 10:05:03 -0400 Received: from mars.hitrost.net ([91.185.193.39]:30739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PA1C1-0005sP-Vq for emacs-orgmode@gnu.org; Sun, 24 Oct 2010 10:05:02 -0400 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, Carsten Dominik >>>> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote: (...) >>>>> 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. >>>> >>> On 10/16/2010 01:32 AM, Carsten Dominik wrote: >>>> 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. I would also find it useful, though I appreciate that it won't be easy. Some of the same purpose is already served by #+PROPERTY: xyz_ALL lines (a kind of tag group) and by tag inheritance (acting like a structured vocabulary in certain contexts, like a notes file structured by topic). But none of this provides the full functionality of structured vocabularies. The Drupal taxonomy module is a nice example. >> On Oct 16, 2010, at 9:26 PM, Robert Horn wrote: >>> 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. >>> > On 10/16/10 4:09 PM, Carsten Dominik wrote: >> I don't think I understand what you mean here. How would that help? >> On 10/23/10 5:15 PM, Robert Horn wrote: > 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. But that's not new, that's what we have now -- the ability to hide away tags in a drawer by making them property values. Isn't the point rather that properties are named? If Org gets a vocabulary structure, it could be restricted to certain named properties. There would be no need to look up the vocabulary tree for tags (which would remain 'flat' keywords by definition), nor for other properties than those defined as having a structured vocabulary. This might save on performance, as well as spare the user some confusion. To build on the example in the Info pages: *** Goldberg Variations :PROPERTIES: :Title: Goldberg Variations :Composer: J.S. Bach :Artist: Glenn Gould :Instrument: Piano :Publisher: Deutsche Grammophon :NDisks: 1 :END: Here :Instrument: would be the only property with a vocab structure, part of which might look something like * Instrument ** Strings *** Lutes *** Harps *** Zithers **** Piano ** Wind ** Percussion So, this item would be one of the matches for a search for `Instrument=Strings'. > > 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. As long as only properties can have structured vocabularies, and not tags, the context will be given by the property name, helping avoid term collisions; a meteorologist could search his CD collection with `instrument=wind' and his research notes with `measurement=wind' without getting them mixed up. (This, again, is what we have today.) > 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. Agree. Since Org is so great for structured lists, thoguh, it would be really tempting to use an Org file to define vocabularies, e.g. as in the Goldberg Variations example above. > 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. Again, this is what is achieved by restricting this functionality to properties. What is not achieved, I'm afraid, is making it any easier to implement the feature on top of existing code. Yours, Christian Moe