Bookmarks need labels, just like Email, tasks, Calendar, ...

Let's see:

* I've tried using my Gmail label system as my To do list. Labels good. Flat labels bad.

* I just had the bright idea of trying to use my Google Chrome bookmarks file as the .. labels, structures, folders ... for tasks and emails and .. whatever.  Whatever has an URL.  Which is a lot of stuff.

Unfortunately, the bookmarks are strict hierarchy. Not labels.

---

Cor!  Everything needs labels.  Everything needs hierarchical nestable folders. It should be possible to label/tag/categorize everything in the same system.  There should not be separate labels for Gmail that do not do hierarchy well, task lists for Gtask that do not do hierarchy at all, and which only allow one classification; hierarchical folders for Bookmarks.

It should be possible to have ONE system.

Sure, it should be possible to see

• Technical
• Computers
• OS
• Linux
• Bookmarked Web Pages
• Mailing lists
• To do

but also 

• Bookmarks
• Technical
• Computers
• OS
• Linux
• Mailing Lists
• Linux [Technical / Computers / OS]

It should not be necessary to duplicate the entire hierarchy, if it is mainly sparse.

Hierarchy is good.  But these are tags.

---

One system.

Memex.

Hardlinks vs. Softlinks

What do we learn from the history of UNIX hardlinks vs. softlinks?

First, UNIX hardlinks did not really help much for directories, because of the implicit assumption of hierarchy. ".." is the parent directory, but what if you have multiply parents?  What if things pount to each other?   You can force directory hardlinks given root, but it is a great way to get screwed up.  I think that on some systems it was possible to create cycles that could lead to inodes being garbage, not refrrable. Memory leaks.

LEARNINGS: be careful.

LEARNING?:  it may be "nice" to have a primary hierarchy, like .. for parent.   But it may also be that we just don't really have the concepts to deal properly with more general graphs.

It was (is) much easier to deal with UNIX hardlinks to files.

But... one could get messed up because rm removed a link to an object, but did not actually remove the object itself.

LEARNING: there must be a way to say "remove the object completely", not just the link.  Hmm... perhaps a notation like "rm ab/b" removing a link, "rm a/b/." removing the object itself.  BTW, I often think of all objects as being directories  Internal structure.

Big problem with hardlinks is not being able to link across filesystems.   No matter how comprehensive your database is, there will always be stuff outside your database.  You will need to link to this outside stuff.   But...  perhaps you can provide all of the goodness of labels, paths, reflexity, etc., for this outside stuff you link to as well as the inside stuff?

Symlinks helped with many of the manageability problems of hardlinks.  At the cost of making things even harder to set up.  (Have you ever managed link farms? ...)

With symlinks, there must be a primary name.

When you move the primary object, symlinks go dead.

(LEARNING: permalinks, etc.)

Symlinks do not really resolve the "how do you remove the object" problem.  You just have to find the non-symlinked name. With hardlinks, there isn't really a non-symlinked name.

Hierarchical labels don't cut it

Some systems have hiearchical labels.

E.g. Gmail - in some configurations Label/Sub appears to have label Label and sublabel Sub - but in reality it is just a label Label/Sub. And many tools that look at Gmail do not know about this hierarcjhy, so present the labels with / paths, flattened. Ugh.

Some tools allow labels to be applied to other labels.

E.g. Android app Folder Organizer (but not in free trial version, so Ihaven't tried).

E.g. Mediawiki categories can be applied to other categories.

This is better, but not quite there.

E.g. I may want to see a hierarchy MailingLists/Linux and Linux/MailingLists, but not all Linux stuff is related to mailing lists.  Most Linux stuff will be Computers/OS/Linux, but some Computers/OS/Linux/MailingList stuff may be purely social.

Put another way: there's a large amount of stuff that should be tagged Linux.  Some will be MailingList related, some not.  Some will be Computers/OS related, but some not.

I see tagging label relationships, such as hierarchies and paths and reflexive relationships, as being more suggestions.  When we tag an object, we may be asked which of the standard relations for that tag will apply.  We can accept default sggestions, or edit at any time.  After the fact, we can query using the relations stored with that object, or also with rel;atins stored with the Labels on that object that are not currently associated with that object - perhaps because you had not set them up when you tagged the object.

I see label relationships, such as hierarchies and paths and reflexive relationships, as being more related to browsing, choosing and selecting tags, and choosing and selecting objects.

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.