Tag items not just with labels, but label paths

Gmail Adds Nested Labels and Message Preview:
'via Blog this'

Brain flash: I was, for the umpteenth time, looking for better mail reading and organization tools, when I re-read this article on Gmail nested labels from 2010.

Which suck.

It sucks that:

Nested Labels is just a cosmetic change that lets you create labels which are displayed hierarchically. If you enable this experiment and create a label like Mailing-Lists/Linux, you'll notice that Linux is displayed as a subfolder of Mailing-Lists. Unfortunately, all the other places that let you interact with labels show the label as Mailing-Lists/Linux.

.. this poor behavior is the default behavior on so many systems that use labels.


My brain flash:  messages, items, tasks need to be tagged not just with a set of labels, but with a set of label-paths.  I.e. label-paths may want to be a top level object.

A label path is a sequence of labels that might otherwise be considered top level independent, but which we are imposing some structure on.

E.g.

• Mailing Lists
• Linux
• Android
• Agile
• Technical
• Operating Systems
• UNIX-like
• Linux
• Kernel
• Distributions
• Mailing Lists
• Android
• Mailing Lists
• iOS
• Solaris
• Windows
• Software Engineering
• Agile
• Mailing Lists

 I have often talked about stuff like this - the issue of which hierarchy:  Mailing List/Linux versus Linux/Mailing List.  Labels get that right.

But I have only recently started thinking of label paths as something that get applied to individual mssages. I have hitherto thought f label paths or hierarchies as being properties of the labels themselves.

Perhaps it should be thought of as browsing similarly labelled objects:  A/B/C/D is equivalent to A&B&C&D, or even the reordered D&C&A&B.  But we can apply the operator "up" to a label-path A/B/C/D to get A/B/C, whereas "up" is not meaningful for commutative A&B&C&D.

Similarly, A/B/C/D/* is equivalent to saying D&A&C&B and ... either any other label or

---

I've been thinking mainly in terms of co-labelling suggestions: applying a label like "Linux" automatically suggests the path Technical/Computers/OS/UNIX-like/Linux.

It is a suggestion, because not all things labelled "Linux" may want to be labelled with the full path.  E.g. I might have something with a label-path Mailing Lists/Linux/Meetup, but I may not want a meetup social invite to appear in my technical hierarchy. (Not by default - but I may want to broaden, sibce sometimes a social invite turns into a place for technical notes get recordered).

---

Is it meaningful to attach a label-path to an item, rather than to the label itself?  I think that I just answered that question: yes.  A social invite may want to be Mailing Lists/Linux/Meetup but not Technical/Computers/OS/UNIX-like/Linux.

But I also want to associate label paths with labels.  So I can just say "Linux", and have the default label paths suggested.

The default label paths may be suggested not just by label, but also by context.  For example, in my to-do list organizer, default paths ToDo/.../Linux may be suggested.   If I am reading an email...

---

Again, think of it as browsing.  Label path hierarchy like a folder tree browser.

Looking at A/B/C  may start off by looking at all items labelled explicitly with the label path A/B/C.

But I may click to widen to A&B&C.

And similarly click to widen to all labelled C.

I think of this latter operation as something that takes me from viewing A/B/C to C.

I think of the folder browser as having (a) the current path tio what you are looking at, and (b) alternate paths that get to the same place.  To give you more ways to go up.  And sideways.

---

Everything I have said about applying label paths is also applicable to applying label DAGs or more general graphs.  Paths are just easy to type.   But I can easily imagine wanting to apply one label and automatically have it appear by default in several places in the "path" oriented browsing hierarchy.