adding semantics to properties

adding semantics to properties

[Austin Frank]

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

Re: adding semantics to properties

[Carsten Dominik]

Hi Austin,

thank you for your detailed post and clearly worked-out proposal.
I can see where you are heading, and some of the ideas are useful.
However, I thing it would be a lot of work to create a system that
uses the existing interfaces in an efficient way.  Since these
interfaces have developed over time, they are not as modular
as one might wish.  Driving coding by real world problems unfortunately
leads to this.

Another way to approach this would be to simply create appropriate
hooks.  For example, we could assign to properties a function that
will be called to edit or set this property, and the user can then
implement different specialized interfaces.  Would you or others be
willing/interested to use such hooks?

- Carsten

On May 16, 2008, at 12:54 AM, Austin Frank wrote:

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