Re: Re: Adding tags, grouping tags

Re: Re: Adding tags, grouping tags

[Karl Maihofer]

Noorul Islam K M <noorul@noorul.com> schrieb:
> I have something like this shamelessly copied from Bernt's doc.
>
> (setq org-tag-alist (quote ((:startgroup)
>                             ("@errand" . ?e)
>                             ("@office" . ?o)
>                             ("@home" . ?h)
>                             (:endgroup)
>                             ("PHONE" . ?p)
>                             ("NEXT" . ?n)
>                             ("WAITING" . ?w)
>                             ("HOME" . ?H)
>                             ("ORG" . ?O))))

Thanks for your reply! Correct me if I'm wrong, but doesn't this  
"only" effect that if you add the tag @office, than add the tag @home,  
the first will be deleted automatically? This is not the kind of  
grouping what I am looking for. For me it should - by the way - be  
possible to add several tags of the same group.

I'd like to use the same selection keys for different tags. For  
example I have the following groups:

Group "people":
- Key "h" -> Holger
- Key "o" -> Otto

Group "contexts":
- Key "h" -> @home
- Key "o" -> @office

To make this possible I think it is necessary to be able to select the  
group in the first step, and then the tag you want to assign - as it  
is possible for agenda groups.

Any ideas?

Re: Re: Adding tags, grouping tags

[Carsten Dominik]

On Oct 15, 2010, at 10:29 AM, Karl Maihofer wrote:

>
> Noorul Islam K M <noorul@noorul.com> schrieb:
>> I have something like this shamelessly copied from Bernt's doc.
>>
>> (setq org-tag-alist (quote ((:startgroup)
>>                            ("@errand" . ?e)
>>                            ("@office" . ?o)
>>                            ("@home" . ?h)
>>                            (:endgroup)
>>                            ("PHONE" . ?p)
>>                            ("NEXT" . ?n)
>>                            ("WAITING" . ?w)
>>                            ("HOME" . ?H)
>>                            ("ORG" . ?O))))
>
> Thanks for your reply! Correct me if I'm wrong, but doesn't this  
> "only" effect that if you add the tag @office, than add the tag  
> @home, the first will be deleted automatically? This is not the kind  
> of grouping what I am looking for. For me it should - by the way -  
> be possible to add several tags of the same group.
>
> I'd like to use the same selection keys for different tags. For  
> example I have the following groups:
>
> Group "people":
> - Key "h" -> Holger
> - Key "o" -> Otto

I use TAB and then completion for people.  Otherwise you run into  
trouble with two people starting with the same name, trusting your  
system too far....


- Carsten

>
> Group "contexts":
> - Key "h" -> @home
> - Key "o" -> @office
>
> To make this possible I think it is necessary to be able to select  
> the group in the first step, and then the tag you want to assign -  
> as it is possible for agenda groups.
>
> Any ideas?
>
>
>
>
> _______________________________________________
> 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

- Carsten

Re: Re: Adding tags, grouping tags

[Karl Maihofer]

Hi Carsten!

Carsten Dominik <carsten.dominik@gmail.com> schrieb:
>> Group "people":
>> - Key "h" -> Holger
>> - Key "o" -> Otto
>
> I use TAB and then completion for people.  Otherwise you run into  
> trouble with two people starting with the same name, trusting your  
> system too far....

Yes, this may be a risk. But the people group was only an example. The  
main reason for me pre-defining the tags and using selection keys is  
that I use org to archive documents. I'd like to assign tags to this  
documents: (1) the names of clients the documents belong to (2) tags  
describing the contents ot the files. To make sure that I do not use  
different tags for the same thing, it is important to see a list of  
the used tags when assigning them. So I have to use pre-defined tags  
and selections keys. Do you know what I mean?

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.

Thanks!
Karl

Re: Re: Adding tags, grouping tags

[Carsten Dominik]

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.

- Carsten

Re: Re: Adding tags, grouping tags

[Robert Horn]

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.

R Horn

Re: Re: Adding tags, grouping tags

[Carsten Dominik]

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

Re: Re: Adding tags, grouping tags

[Robert Horn]

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

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

Re: Re: Adding tags, grouping tags

[Carsten Dominik]

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

Re: Re: Adding tags, grouping tags

[Robert Horn]

On 10/25/2010 02:18 AM, Carsten Dominik wrote:
> 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?
> 

I think so.

My impression is that the present normal tags are approaching their
limit.  A multi-level normal tag will probably be longer text, and one
core assumption of normal tags is that it is reasonable to display them
and simply append them to the end of the headline text.  With longer
tags and multiple tag contexts I expect this to soon cause problems that
are much more severe than just the problem of tag specification.

Since there exists the properties capability, a more complex structure
that is used in searches and display could be built upon that.

R Horn

Re: Re: Adding tags, grouping tags

[Karl Maihofer]

Carsten wrote:
>> 2. A complex new structure that would somehow utilize properties to
>>    crease a tag-like parallel structure that can be used in searches.

I think it is a interesting idea to use properties for an "extended"  
use of tags.

My first attempt to implement my use of tags to organize my documents  
in orgmode:

* Title of the memo                                    :ATTACH:
  :PROPERTIES:
  :Attachments: Memo.pdf
  :ID:       e77dc30e-53c4-4dde-b451-e2g8aa8964c
  :Topic_ALL: Topic1 Topic2 Topic3
  :Client_ALL: Client1 Client2 Client3
  :Topic:
  :Client:
  :END:

I use an org-capture template that gives me the structure above to  
save new entries to my orgmode-based collection of documents. In the  
example above the name of the property item is something like a tag  
group. This enables me to insert tags easily (I can use "C-c C-x p Cl  
TAB RET" and then scroll through the possible values defined by *_ALL  
using the arrow keys). But since the client-entry can only have one  
value, the memo can concern different topics... but the property  
"Topic" can only have one value, of course.

I think it would not be nice to use "topic_one", "topic_two" and  
"topic_three" as properties to be prepared for these cases where an  
entry can have more than one value.

Any ideas on how to realize multible tags (being in the same group)  
per entry using the properties function?