* "Tag hierarchy" idea
@ 2011-03-21 23:09 John Tait
2011-03-22 0:57 ` Matt Lundin
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: John Tait @ 2011-03-21 23:09 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
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?
[-- Attachment #2: Type: text/html, Size: 3247 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
2011-03-21 23:09 "Tag hierarchy" idea John Tait
@ 2011-03-22 0:57 ` Matt Lundin
[not found] ` <AANLkTikwOWJdqKrZDE+JUzezEpvfNQ537xRgtzYgssAd@mail.gmail.com>
2011-03-22 4:08 ` Jambunathan K
2011-03-22 8:27 ` Christian Moe
2 siblings, 1 reply; 8+ messages in thread
From: Matt Lundin @ 2011-03-22 0:57 UTC (permalink / raw)
To: John Tait; +Cc: emacs-orgmode
John Tait <johngtait@gmail.com> writes:
>
> 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?
Alas, I believe exclude tags only work with trees (not filetags).
According to the docstring of org-export-handle-export-tags, "If any of
SELECT-TAGS is found, all *trees* not marked by a SELECT-TAG will be
removed (emph. mine)."
Best,
Matt
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
2011-03-21 23:09 "Tag hierarchy" idea John Tait
2011-03-22 0:57 ` Matt Lundin
@ 2011-03-22 4:08 ` Jambunathan K
2011-03-22 8:27 ` Christian Moe
2 siblings, 0 replies; 8+ messages in thread
From: Jambunathan K @ 2011-03-22 4:08 UTC (permalink / raw)
To: John Tait; +Cc: emacs-orgmode
> May I propose an additional feature?
> We could assign tags to hierarchies of other tags.
As a technical editor how do you think you would make use of
hierarchical tags. Without getting in to how this feature might be
implemented, if you can articulate your particular requirements and your
particular workflow there is a likelihood that someone picks the ball
and runs from there on.
My comments are not meant as a criticism but just a thought.
Jambunathan K.
--
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
2011-03-21 23:09 "Tag hierarchy" idea John Tait
2011-03-22 0:57 ` Matt Lundin
2011-03-22 4:08 ` Jambunathan K
@ 2011-03-22 8:27 ` Christian Moe
2011-03-22 13:57 ` John Tait
2 siblings, 1 reply; 8+ messages in thread
From: Christian Moe @ 2011-03-22 8:27 UTC (permalink / raw)
To: John Tait; +Cc: emacs-orgmode
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?
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
2011-03-22 8:27 ` Christian Moe
@ 2011-03-22 13:57 ` John Tait
2011-03-24 11:34 ` Jambunathan K
0 siblings, 1 reply; 8+ messages in thread
From: John Tait @ 2011-03-22 13:57 UTC (permalink / raw)
To: mail; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 7053 bytes --]
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 <mail@christianmoe.com>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?
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 8620 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
[not found] ` <AANLkTikwOWJdqKrZDE+JUzezEpvfNQ537xRgtzYgssAd@mail.gmail.com>
@ 2011-03-22 14:17 ` Matt Lundin
0 siblings, 0 replies; 8+ messages in thread
From: Matt Lundin @ 2011-03-22 14:17 UTC (permalink / raw)
To: John Tait; +Cc: Org Mode
John Tait <johngtait@gmail.com> writes:
> Thanks for that. But then what are #-FILETAGS for?
>
FILETAGS are primarily used in the agenda -- i.e., filetags are
inherited by the entire file, so when you filter the agenda by tags, the
filetags are also considered.
Not much work has been done to integrate filetags with export.
Perhaps this should be a feature request?
Best,
Matt
> John
>
>
>> Alas, I believe exclude tags only work with trees (not filetags).
>> According to the docstring of org-export-handle-export-tags, "If any of
>> SELECT-TAGS is found, all *trees* not marked by a SELECT-TAG will be
>> removed (emph. mine)."
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
2011-03-22 13:57 ` John Tait
@ 2011-03-24 11:34 ` Jambunathan K
2011-03-24 22:27 ` John Tait
0 siblings, 1 reply; 8+ messages in thread
From: Jambunathan K @ 2011-03-24 11:34 UTC (permalink / raw)
To: John Tait; +Cc: emacs-orgmode
IIUC, what you are saying is that you would like to define few atomic
tags and a few composite tag. A composite tag is presumably a union of
some of those atomic tags. You need an ability to selectively export of
the items that fall under the composite tag.
Orgmode allows selective viewing (and exporting) of tagged documents. I
think all you need is to define a query and export only the visible
portion of the document. (I don't use tagging much but you can get
useful information from the manual)
It still it beats me how would you solve the problem of migrating
existing word documents in to Orgmode. Looks like that is a much bigger
problem right there than the lack of facility for elaborate hierarchical
organization.
Jambunathan K.
John Tait <johngtait@gmail.com> writes:
> 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 <mail@christianmoe.com> 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?
>
>
>
>
>
>
>
>
--
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: "Tag hierarchy" idea
2011-03-24 11:34 ` Jambunathan K
@ 2011-03-24 22:27 ` John Tait
0 siblings, 0 replies; 8+ messages in thread
From: John Tait @ 2011-03-24 22:27 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
Thanks Jambunathan K. Your concise summary is correct.
As it stands, selective export from Orgmode is already excellent --
combining both #+EXPORT_SELECT_TAGS: and #+EXPORT_EXCLUDE_TAGS: in various
ways allows for very precise exporting; this is particularly apparent when
dealing with tags at different heading levels.
I am particularly thinking about largish publishing projects, where it would
be less easy to add manage individual tags at the level of the heading.
Building groups of composite tags from small groups of atomic tags, as
needed, and then exporting/excluding those composite tags (plus other atomic
tags) would be a neat way of managing this. The atomic tags could remain
fairly static and the composite tags could be juggled as needed.
Migrating stuff to Orgmode isn't a big deal -- the interesting part is using
the information once it's there.
As I hope is clear, I think Org is fantastic as it stands. For the type of
thing I am (already) doing, the only other real solutions are DITA-based --
and Org is a whole lot more fun.
John
On Thu, Mar 24, 2011 at 11:34 AM, Jambunathan K <kjambunathan@gmail.com>wrote:
>
> IIUC, what you are saying is that you would like to define few atomic
> tags and a few composite tag. A composite tag is presumably a union of
> some of those atomic tags. You need an ability to selectively export of
> the items that fall under the composite tag.
>
> Orgmode allows selective viewing (and exporting) of tagged documents. I
> think all you need is to define a query and export only the visible
> portion of the document. (I don't use tagging much but you can get
> useful information from the manual)
>
> It still it beats me how would you solve the problem of migrating
> existing word documents in to Orgmode. Looks like that is a much bigger
> problem right there than the lack of facility for elaborate hierarchical
> organization.
>
> Jambunathan K.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2377 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in threadend of thread, other threads:[~2011-03-24 22:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-21 23:09 "Tag hierarchy" idea John Tait
2011-03-22 0:57 ` Matt Lundin
[not found] ` <AANLkTikwOWJdqKrZDE+JUzezEpvfNQ537xRgtzYgssAd@mail.gmail.com>
2011-03-22 14:17 ` Matt Lundin
2011-03-22 4:08 ` Jambunathan K
2011-03-22 8:27 ` Christian Moe
2011-03-22 13:57 ` John Tait
2011-03-24 11:34 ` Jambunathan K
2011-03-24 22:27 ` John Tait
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).