From: Christian Moe <mail@christianmoe.com>
To: rjhorn@alum.mit.edu
Cc: emacs-orgmode@gnu.org, Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: Re: Adding tags, grouping tags
Date: Sun, 24 Oct 2010 16:06:09 +0200 [thread overview]
Message-ID: <4CC43D51.2000907@christianmoe.com> (raw)
In-Reply-To: <4CC2FC16.9050202@alum.mit.edu>
>>>> 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
next prev parent reply other threads:[~2010-10-24 14:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-23 15:15 Re: Adding tags, grouping tags Robert Horn
2010-10-24 14:06 ` Christian Moe [this message]
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=4CC43D51.2000907@christianmoe.com \
--to=mail@christianmoe.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=rjhorn@alum.mit.edu \
/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).