From: Robert Horn <rjhorn@alum.mit.edu>
To: emacs-orgmode@gnu.org
Subject: Re: Re: Adding tags, grouping tags
Date: Sat, 23 Oct 2010 11:15:34 -0400 [thread overview]
Message-ID: <4CC2FC16.9050202@alum.mit.edu> (raw)
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
next reply other threads:[~2010-10-23 15:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-23 15:15 Robert Horn [this message]
2010-10-24 14:06 ` Re: Adding tags, grouping tags Christian Moe
2010-10-25 6:18 ` Carsten Dominik
2010-10-25 11:14 ` Robert Horn
2010-10-26 17:17 ` Karl Maihofer
-- strict thread matches above, loose matches on Subject: below --
2010-10-14 18:22 Karl Maihofer
2010-10-15 5:55 ` Noorul Islam K M
2010-10-15 8:29 ` Karl Maihofer
2010-10-15 8:35 ` Carsten Dominik
2010-10-15 8:52 ` Karl Maihofer
2010-10-15 14:43 ` Ilya Shlyakhter
2010-10-16 5:32 ` Carsten Dominik
2010-10-16 19:26 ` Robert Horn
2010-10-16 20:09 ` Carsten Dominik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC2FC16.9050202@alum.mit.edu \
--to=rjhorn@alum.mit.edu \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).