From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Tait Subject: Re: "Tag hierarchy" idea Date: Tue, 22 Mar 2011 13:57:59 +0000 Message-ID: References: <4D885D7A.70804@christianmoe.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015174bf276c5d7d1049f12a19c Return-path: Received: from [140.186.70.92] (port=44324 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q225y-0007Yc-Vc for emacs-orgmode@gnu.org; Tue, 22 Mar 2011 09:58:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q225w-00047o-UQ for emacs-orgmode@gnu.org; Tue, 22 Mar 2011 09:58:02 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:43108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q225w-00047Z-HE for emacs-orgmode@gnu.org; Tue, 22 Mar 2011 09:58:00 -0400 Received: by ewy9 with SMTP id 9so1894683ewy.0 for ; Tue, 22 Mar 2011 06:57:59 -0700 (PDT) In-Reply-To: <4D885D7A.70804@christianmoe.com> 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: mail@christianmoe.com Cc: emacs-orgmode@gnu.org --0015174bf276c5d7d1049f12a19c Content-Type: text/plain; charset=ISO-8859-1 Thanks for your replies. I'm using org-mode both as an organiser and also as a way of composing modular documents with conditional text (controlled by both tags and #+INCLUDE). The problem I am trying to solve is one I encounter in my day job. Basically, I am sitting on top on hundreds of legacy Word documents, each filled with technical requirements aimed at different audiences. Each document can itself be aimed at different people and contain various subjects. This is a typical legacy document problem. It is horrible. Occasionally, we have to update vast amounts of this stuff as a batch, to reflect organisational change or other initiative. It is a manual slog. I am naturally drawn to dealing with this via some kind of structured document solution. This main problem here is that the information is inherently unstructured. It awas never written with structure in mind. It is impossible to impose a structure upon it without starting again. Attempts by management to enter all this stuff into the IBM DOORS requirements "database" have been so far been of only "limited success". We still get asked to produce tailored, filtered summarised information. These requests usually aren't satisfactorily resolved because a mountain of crumbling Word documents isn't a good starting point. That's the problem. Structured documents are an ideal, but totally impractical. Examples of requests might be: -- show me all the (railway) level crossing requirements in one place. -- show all everything to do with track patrolling. -- show all everything to do with track patrolling that a track patroller needs to see (no process or other office stuff). -- show me everything a Senior Engineer needs to know about this. etc. So there is a certain concept hierarchy beginning to form, but one that is fluid and maybe only needed once. I don't want to apply lots of tags only to have to add fresh tags later if ideas change. On the other hand, some tags would be pretty stable (:level-crossings:), especially if I was to use an abstraction (":M123:") in place, so I could change the definition of the tags slightly without altering the tag. (The definition of ":M123:" could, say, change from "Level crossing" to "Level crossing and road--rail access points".) (I used to work for Derwent Patents, applying concept tags to patents for help with patent searches, so this actually works.) The power of a tag hierarchy could be that I could alter and create groups for export very easily. It hard to come up with concrete examples for something that is just an idea but I will try. Say there are tags called :level-crossing: and :road--rail-access: If I could have a meta tag called ":access: that I could assign :level-crossing: and :road--rail-access: to, I could just use a single tag. Later, I could add ":gates:" to ":access:." and include those. Later, I could have a new meta tag called :roads:, and include ":level-crossing:" and "road-bridge". Then I could have a meta tag called ":patrol:", and include tags for ":level-crossing:" and ":patroller:". I hope I am illustrating this well enough. The point is that adding individual tags to headings could be complimented by grouping them under top level tags. The top level tags could be added to heading as well for maximum flexibility. This would provide awesome control and flexibility! Thanks for your time! John On Tue, Mar 22, 2011 at 8:27 AM, Christian Moe wrote: > Hi, > > There was some discussion of tag hierarchies in this thread: > > http://thread.gmane.org/gmane.emacs.orgmode/31882 > > It was largely inconclusive, except that it would be hard to implement. > Noone took the ball and ran with it, but then noone came up with a strong > use case or specification, either. Anyway, I recommend a look at that thread > before continuing it here. > > Yours, > Christian > > > On 3/22/11 12:09 AM, John Tait wrote: > >> Hi all >> >> This is my first post. First, I'd like to thank all the org-mode >> developers for a great tool. >> >> I'm a technical editor. I am facinated by the pros and cons of >> structured documents with regard to their ease of use and power. I >> think that they are probably far too restrictive and cumbersome >> (looking at you, DITA) for the average technical document. >> Nevertheless, the idea of modular documents is an appealing one to me. >> I like conditional text features (e.g. in LyX). >> >> In org-mode, I really really love selective export (include/exclude >> tags) and using #+INCLUDE: for including other files. This gives me >> enormous flexibility, with zero DITA pain. >> >> May I propose an additional feature? I haven't seen anything like it >> published anywhere, though maybe I am using the incorrect search >> terms. (I am getting enormous vertigo and time-travel sickness reading >> up on Lisp, XML, DITA, etc.) >> >> It's a pretty basic idea, but I hope you can take a moment to weigh up >> its potential. >> >> We could assign tags to hierarchies of other tags. >> >> >> #+TAG-NEST: (colour(red green blue)) >> #+TAG-NEST: (type(colour size)) >> #+TAG-NEST: (car(type price)) >> >> or maybe like this. I'd leave it up to someone with actual programming >> experience and a logical mind (my productive programming was PASCAL in >> 1991) to suggest a rigorous system that makes sense. >> >> #+TAG-NEST: colour > red:green:blue >> #+TAG-NEST: type > colour:size >> #+TAG-NEST: car > type:price >> >> The point of this would be that selecting, say, "colour" as a tag >> would bring along "red", "green", and "blue" along with it. The tag >> "type" would bring "colour", "red", "green", "blue" and "size" with it. >> >> The power of this would be that hierarchies could be adjusted and >> manipulated as necessary. >> >> Since there is no one definitive way to tag real world objects and >> ideas into nice nested boxes (thanks, AI research), we could adjust >> any tag hierarchies to suit experience and changing priorities. Even >> hierarchies could just be thrown away without affecting existing tags >> too much, since tagged headings could just be selected/excluded as usual. >> >> This way, we can use concept hierarchies as the disposable >> conveniences that they are, without getting locked into them. Looking >> at stuff like XSLT transformation for XML, that'd be worth avoiding. >> >> Maybe there is some logical lispy reason why this couldn't work, but I >> hope this is worthy of your consideration. >> >> John >> >> ------ >> >> While I am here (sorry), I couldn't get #+FILETAGS: to work in >> org-version 7.4. >> >> For example, if I export a file (to html) File1.org with >> "#+EXPORT_EXCLUDE_TAGS: john", and then I include File2.org, I can see >> File2.org included as part the export of File1 as expected. If I then >> set "#+FILETAGS: :john:" in File2, I'd expect File2 to now be >> excluded, but it still appears. If I then tag a File2 heading as say >> "* Heading :john:", then it won't appear in the File1 export, as >> expected. Am I missing something? >> >> > --0015174bf276c5d7d1049f12a19c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your replies.
=A0
I'm using org-mode both as an organiser and also as a way of compo= sing modular documents with conditional text (controlled by both tags and #= +INCLUDE).
=A0
The problem I am trying to solve is one I encounter in my day job. Bas= ically, I am sitting on top on hundreds of legacy Word documents, each fill= ed with technical requirements aimed at different audiences. Each document = can itself be aimed at different people and contain various subjects. This = is a typical legacy document problem. It is horrible.
=A0
Occasionally, we have to update vast amounts of this stuff as a batch,= to reflect organisational change or other initiative. It is a manual slog.=
=A0
I am naturally drawn to dealing with this via some kind of structured = document solution. This main problem here is that the information is inhere= ntly unstructured. It awas never written with structure in mind. It is impo= ssible to impose a structure upon it without starting again.
=A0
Attempts by management to enter all this stuff into the IBM DOORS requ= irements "database" have been so far been of only "limited s= uccess".
=A0
We still get asked to produce tailored, filtered summarised informatio= n. These requests usually aren't satisfactorily resolved because a moun= tain of=A0crumbling Word documents isn't a good starting point.
=A0
That's the problem. Structured documents are an ideal, but totally= impractical.
=A0
Examples of requests might be:
=A0
=A0=A0-- show me all the (railway) level crossing requirements in one = place.
=A0 -- show all everything to do with track patrolling.
=A0-- show all everything to do with track patrolling that a track pat= roller needs to see (no process or other office stuff).
=A0-- show me everything a Senior Engineer needs to know about this.
=A0
etc.
=A0
So there is a certain concept hierarchy beginning to form, but one tha= t is fluid and maybe only needed once.
=A0
I don't want to apply lots of tags only to have to add fresh tags = later if ideas change. On the other hand, some tags would be pretty stable = (:level-crossings:), especially if I was to use an abstraction (":M123= :") in place, so I could change the definition of the tags slightly wi= thout altering the tag. (The definition of ":M123:" could, say, c= hange from "Level crossing" to "Level crossing and road--rai= l access points".)
=A0
(I used to work for Derwent Patents, applying concept tags to patents = for help with patent searches, so this actually works.)
=A0
The power of a tag hierarchy could be that I could alter and create gr= oups=A0for export=A0very easily. It hard to come up with concrete examples = for something that=A0is just an idea but I will try.
=A0
Say there are tags called :level-crossing: and :road--rail-access:=A0 = If I could have a meta tag called ":access: that =A0I could assign :le= vel-crossing: and :road--rail-access:=A0 to, I could just use a single tag.=
=A0
Later, I could add ":gates:" to ":access:." and in= clude those.
=A0
Later, I could have a new meta tag called :roads:, and include ":= level-crossing:" and "road-bridge".
=A0
Then I could have a meta tag called ":patrol:", and include = tags for ":level-crossing:" and ":patroller:".
=A0
I hope I am illustrating this well enough. The point is that adding in= dividual tags to headings could be complimented by grouping them under=A0to= p level tags. The top level tags could be added to heading as well for maxi= mum flexibility.
=A0
This would provide awesome control and flexibility!
=A0
Thanks for your time!
=A0
John
=A0


=A0
On Tue, Mar 22, 2011 at 8:27 AM, Christian Moe <= span dir=3D"ltr"><mail@christia= nmoe.com> wrote:
Hi,

There was some discus= sion of tag hierarchies in this thread:

http://thread.gmane.org= /gmane.emacs.orgmode/31882

It was largely inconclusive, except that it would be hard to implement.= Noone took the ball and ran with it, but then noone came up with a strong = use case or specification, either. Anyway, I recommend a look at that threa= d before continuing it here.

Yours,
Christian=20


On 3/22/11 12:09 AM, John Tait wrote:
Hi all

This is my first p= ost. First, I'd like to thank all the org-mode
developers for a grea= t tool.

I'm a technical editor. I am facinated by the pros and cons of
s= tructured documents with regard to their ease of use and power. I
think = that they are probably far too restrictive and cumbersome
(looking at yo= u, DITA) for the average technical document.
Nevertheless, the idea of modular documents is an appealing one to me.
I= like conditional text features (e.g. in LyX).

In org-mode, I really= really love selective export (include/exclude
tags) and using #+INCLUDE= : for including other files. This gives me
enormous flexibility, with zero DITA pain.

May I propose an addition= al feature? I haven't seen anything like it
published anywhere, thou= gh maybe I am using the incorrect search
terms. (I am getting enormous v= ertigo and time-travel sickness reading
up on Lisp, XML, DITA, etc.)

It's a pretty basic idea, but I hop= e you can take a moment to weigh up
its potential.

We could assig= n tags to hierarchies of other tags.


#+TAG-NEST: (colour(red gre= en blue))
#+TAG-NEST: (type(colour size))
#+TAG-NEST: (car(type price))

or = maybe like this. I'd leave it up to someone with actual programming
= experience and a logical mind (my productive programming was PASCAL in
1991) to suggest a rigorous system that makes sense.

#+TAG-NEST: col= our > red:green:blue
#+TAG-NEST: type > colour:size
#+TAG-NEST:= car > type:price

The point of this would be that selecting, say,= "colour" as a tag
would bring along "red", "green", and "blue" = along with it. The tag
"type" would bring "colour", = "red", "green", "blue" and "size" w= ith it.

The power of this would be that hierarchies could be adjusted and
ma= nipulated as necessary.

Since there is no one definitive way to tag = real world objects and
ideas into nice nested boxes (thanks, AI research= ), we could adjust
any tag hierarchies to suit experience and changing priorities. Even
hie= rarchies could just be thrown away without affecting existing tags
too m= uch, since tagged headings could just be selected/excluded as usual.

This way, we can use concept hierarchies as the disposable
convenien= ces that they are, without getting locked into them. Looking
at stuff li= ke XSLT transformation for XML, that'd be worth avoiding.

Maybe = there is some logical lispy reason why this couldn't work, but I
hope this is worthy of your consideration.

John

------
While I am here (sorry), I couldn't get #+FILETAGS: to work in
org-= version 7.4.

For example, if I export a file (to html) File1.org =A0= with
"#+EXPORT_EXCLUDE_TAGS: john", and then I include File2.org, I ca= n see
File2.org included as part the export of File1 as expected. If I t= hen
set "#+FILETAGS: :john:" in File2, I'd expect File2 to= now be
excluded, but it still appears. If I then tag a File2 heading as say
&qu= ot;* Heading :john:", then it won't appear in the File1 export, as=
expected. Am I missing something?



--0015174bf276c5d7d1049f12a19c--