Re: [Orgmode] Re: Adding tags, grouping tags

[Christian Moe]

> > > > 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