adding semantics to properties

[Austin Frank <austin.frank@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4012 bytes --]

Hello all--

I recently had an idea for a possible generalization of some existing
org-mode functionality, and I wonder whether others would find it useful
and whether implementing it seems feasible.

One way to think of org is as program for creating structured texts with
the ability to associate arbitrary meta-data at any point in the
hierarchy.  This meta-data comes in two general forms:  structured and
unstructured.  Structured meta-data in org includes todo state, priority
level, tags, deadlines, schedules, timeclocks, categories, and probably
some others that I'm forgetting.  Unstructured meta-data is stored in
properties.  My proposal is that we add the ability to store structured
meta-data in properties.

The current forms of structured meta-data fall into classes with similar
functionality.  Most importantly, we have interfaces for adding,
manipulating, and searching tags, timestamps, and states.  As org has
developed, we've seen the addition of different todo cycles and tag
sets.  I think it would be useful not only to be able to define these
different sets, but to store them independently as well.

I propose that users should be able to declare that a given property has
a particular kind of interpretation, and that in doing so they gain
access to org's existing interfaces for that kind of information.  For
example, rather than having a single tag line that holds all of my
tag-like information about an entry, I could split the tags up into
meaningful classes in properties of the entry.  For example, when I go
to set the PEOPLE property, I would get to use org's tag selection
interface rather than plain text entry.  In another case, I might have
multiple todo cycles that are relevant to the same entry:  I could have
a WRITING property that used todo semantics, and an associated todo
cycle, and I could still have my general todo cycle stored in the
default TODO property using its own cycle.


To be a bit more concrete, I'm proposing that an entry like

#v+
* NEXT Research project :advisor1:advisor2:computer:office:writing:analysis:
#v-

could actually be stored as something like

#v+
:PROPERTIES:
:TODO: NEXT
:WRITING: EDIT
:PEOPLE: :advisor1:advisor2:
:EQUIPMENT: :computer:
:LOCATION: :office:lab:
:TASK_TYPE: :writing:analysis:
:END:
#v-

Important to note are that I have multiple banks of tags and multiple
todo cycles within a single entry.  The display of the headline could be
almost the same-- display the union of all the tags from all of
properties using tag semantics, and maybe display only one todo state by
default.

I envision this sort of setup would being based on user configurations
like:

#v+
(setq org-tag-alist '((:PEOPLE:)
                      ("advisor1" . ?a)
                      ("advisor2" . ?b))
      org-todo-keywords '((:WRITING:)
                          ("DRAFT" "EDIT" "DISTRIBUTE" "REVISE" "|" "SUBMIT")))

(org-declare-property "PEOPLE" 'tagged)
(org-declare-property "WRITING" 'cycled)
(org-declare-property "LAST_REVISED" 'timestamped)
#v-

With a setup like this, when I did C-c C-x C-p PEOPLE, I would get a tag
selection interface that included tags only from the PEOPLE tagset.  C-c
C-x C-p WRITING would let me cycle through the appropriate todo states.
C-c C-x C-p LAST_REVISED would give me the timestamp entry dialog.

Given that there are already a set of special properties that use each
of the above semantics, my proposal boils down to letting users declare
their own "special" properties with those same semantics.

Org is clearly a great tool already.  In fact, I like its different
interfaces so much that I want to be able to use them in even more ways.
Do people think this generalization of existing org interfaces to
arbitrary properties is an interesting idea?  Would you use it?

Thanks for your thoughts,
/au

-- 
Austin Frank
http://aufrank.net
GPG Public Key (D7398C2F): http://aufrank.net/personal.asc

[-- Attachment #1.2: Type: application/pgp-signature, Size: 193 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode