True hierarchical tags

[Rob Freundlich 146]

It's great that tags can now be nested in other tags. But the only way to create a tag hierarchy is by going to the tags list, right-clicking a tag, and selecting "Create tag in this tag's name" or by dragging a tag into another tag.

In other applications, hierarchies are represented by delimited sequences of names. In programming, we have object.property.subproperty; in file systems, we have folder/subfolder/subsubfolder. I propose an option in settings that lets the user specify the tag hierarchy delimiter, so that if s/he types a tag containing that delimiter, a set of nested tags is automatically created.

So, for example, if my delimiter is period ("."), then when I tag a note with financial.receipt.medical, EN would look for a tag called medical in a tag called receipt in a tag called financial, creating the hierarchy if necessary. It would be as though I created a tag called financial, right clicked it and said "Create tag in financial" and called it receipt, and then repeated that to create medical, only about a zillion times easier.

The full name of this tag should be financial.receipt.medical, but I should be able to find it in all searches by simply typing medical - that is, all tag searches should be infix searches.

[DTLow 5,736]

There is a "true" hierarchy for Tags (parent/child)
It's not accessible on the IOS platform, but I make use it on a Mac.

The notation would be a good addition to the tree UI and drag-and-drop.

[JMichaelTX 4,117]

1 hour ago, Rob Freundlich said:

a tag containing that delimiter, a set of nested tags is automatically created.

 I agree. I think that’s a great idea. 

[Rob Freundlich 146]

34 minutes ago, DTLow said:

There is a "true" hierarchy for Tags (parent/child)
It's not accessible on the IOS platform, but I make use it on a Mac.

The notation would be a good addition to the tree UI and drag-and-drop.

I get that it's got parent/child relationships, but I feel like without the notation, it isn't really a true hierarchy. Probably me being pedantic. I'm good at that :-)

[Rob Freundlich 146]

47 minutes ago, Rob Freundlich said:

I get that it's got parent/child relationships, but I feel like without the notation, it isn't really a true hierarchy. Probably me being pedantic.

So, I just played around with changing some of my delimited tags into non-delimited, and learned that the tag hierarchy isn't a true hierarchy in a couple of other ways. Suppose I've got a hierarchy like this:

• foo
  • foo.bar
    • foo.bar.baz
• test
  • test.something
    • test.something.baz

If I search for tag:foo*, I find all notes tagged with foo, foo.bar, and foo.bar.baz. That's really nice, and it's akin to searching a file system for all files in directory foo (including subdirectories).

I decided to simplify my naming scheme to see how it would work without the dots, since they aren't required by EN, and immediately realized a limitation. It wouldn't let me do this:

• foo
  • bar
    • baz
• test
  • something
    • baz

The problem is that there can't be two tags named baz, even though, hierarchically, they are different. In a true hierarchy, like a file system, this would be just fine. I can certainly have README.txt in two different directories - the unique identifier for a file is its full path, not its filename.

So I worked around it and did this:

• foo
  • bar
    • baz
• test
  • something
    • baz2

But then when I tried to search for tag:foo*, only notes tagged with foo were found; notes tagged with bar and baz were not. It was akin to doing a directory listing of only directory foo (which I would have expected to be a search for tag:foo), not the full search of directory foo and its subdirectories.

If my proposal is implemented, this is all solved:

1. A tag can be uniquely identified by its fully delimited path, allowing multiple tags with the same atomic name
2. A search syntax can be added to differentiate between "search for notes only with this tag and tags like it" (i.e. "directory listing of directories whose names match foo*") and "search for notes whose fully delimited paths match this sequence (i.e "find files in directories whose names match foo* and their subdirectories"). I'd suggest tag:foo* for the first and tag:foo*.* (or whatever the user's delimiter is), or maybe tag:foo** for the second one.

[jefito 5,589]

On 1/11/2019 at 1:35 PM, Rob Freundlich said:

In other applications, hierarchies are represented by delimited sequences of names. In programming, we have object.property.subproperty; in file systems, we have folder/subfolder/subsubfolder. I propose an option in settings that lets the user specify the tag hierarchy delimiter, so that if s/he types a tag containing that delimiter, a set of nested tags is automatically created.

Some applications do this sort of thing. Just a test, in Windows, cmd.exe works this way (e.g., c:\temp> md test\test2 does indeed create subfolder test, and then creates subfolder test2 in that). In Explorer, though, not so much. I can't speak to +x based OS'es. Even so, it's a fair ask, though with, I suspect, a pretty limited audience. If Evernote for Windows had better scripting support, (like more than "very limited") this would a natural feature for it.

On 1/11/2019 at 1:35 PM, Rob Freundlich said:

The full name of this tag should be financial.receipt.medical, but I should be able to find it in all searches by simply typing medical - that is, all tag searches should be infix searches.

If this means searches like tag:blah, then I'd think that it's not the case that "all tag searches should be infix", since it would break existing searches, though I certainly think that there should be an option for that (as well as infix text searches). Pick your favorite syntax: tag:*medical*, tagcontains:medical, or whatever. They can go in the same bin with proposed syntaxes for subtag searches (e.g. https://discussion.evernote.com/topic/15173-shouldnt-selecting-a-parent-tag-search-child-tags/?tab=comments#comment-74067 for one).

 

[DTLow 5,736]

On 1/11/2019 at 1:15 PM, Rob Freundlich said:

The problem is that there can't be two tags named baz, even though, hierarchically, they are different. 

Confirmed: tag names must be unique

You'll also find the Evernote tag hierarchy is only available on specific pages, on specific platforms.
Elsewhere, we're working with an alphabetic list of tags; duplicate names would be difficult to use in the list unless the hierarchy is also identified (like your notation)

>>So I worked around it and did this:
>>foo
>>   bar
>>      baz
>>test
>>   something
>>      baz2

My preference is to prefix tagnames with the parent
     foo
        foo-bar
           foo-bar-baz          
     test
        test-something
           test-something-baz

or use completely independent tags with no structure; can "baz" stand on it's own as a tag
                                                                                                do we want to "baz" tags
For example, if it was the colour "blue", I would not add it as a sub-tag under bar

[jefito 5,589]

18 minutes ago, Rob Freundlich said:

The problem is that there can't be two tags named baz, even though, hierarchically, they are different. In a true hierarchy, like a file system, this would be just fine. I can certainly have README.txt in two different directories - the unique identifier for a file is its full path, not its filename.

Oh, Evernote's tag system does form a "true" hierarchy all right. There's nothing in the definition of hierarchy that forbids hierarchy members from being required to be unique (from. Wikipedia: "A hierarchy (from the Greek hierarkhia, "rule of a high priest", from hierarkhes, "president of sacred rites") is an arrangement of items (objects, names, values, categories, etc.) in which the items are represented as being "above", "below", or "at the same level as" one another."). That's just the rules of this hierarchy. Company structures often form hierarchies as well, and assuming that no person can fill different slots, you have an analogous situation. Evernote's tag hierarchy is just a different flavor than that of your favorite file system.

BTW, this uniqueness requirement is enforced in the Evernote API on a per-account basis: http://dev.evernote.com/doc/reference/Types.html#Struct_Tag:

Quote

A sequence of characters representing the tag's identifier. Case is preserved, but is ignored for comparisons. This means that an account may only have one tag with a given name, via case-insensitive comparison, so an account may not have both "food" and "Food" tags. May not contain a comma (','), and may not begin or end with a space

 

[CalS 5,280]

2 hours ago, Rob Freundlich said:

The problem is that there can't be two tags named baz, even though, hierarchically, they are different

Thing of it is, if baz actually represents the same "thing" in both hierarchies then an independent baz tag will find all notes that are"baz" like the leading foo search.  Just can't represent it in a physical hierarchical tag structure.  Hierarchy versus relational. 

Age old example, but I went paperless with EN so I download/scan all statements.  I have a tag Statement and a tag for each account, two tags per statement basically.  I don't have Account.Statement tags.  Other notes exist for accounts, like type of vehicle for insurance companies, so one ends up with three tags - account, statement, vehicle.  Tag searches can slice in whatever direction.

No new news here.  No issues if EN added this or nested notebooks.  Probably wouldn't use it being a confirmed tagger.  But I do realize not everyone views the world with the same taxonomy.  🤷‍♂️

[JMichaelTX 4,117]

40 minutes ago, CalS said:

I have a tag Statement and a tag for each account, two tags per statement basically.  I don't have Account.Statement tags.  Other notes exist for accounts, like type of vehicle for insurance companies, so one ends up with three tags - account, statement, vehicle.  Tag searches can slice in whatever direction.

So tags can be used in multiple ways.  One way, your example (which I also use), is what I call a cross-topic, or cross-category, use.  So, there is no parent tag to the "statement" tag, and none is needed.

If Evernote supported what @Rob Freundlich requested, then tags could also be used to uniquely identify Notes in a Parent.Child hierarchy.

A good example might be projects, which most often have a standard set of hierarchical topics, as in:  Project1.Resources.People

An interesting extension of Rob's request is to allow a child tag to be used either in "stand-alone" mode, or in Parent.Child mode.  So if I search just for "tag:People", then it would find all Notes that used the "People" tag in either stand-alone mode or in a hierarchy.  Thus, it would, for example, for all Notes for Project1, Project,2, etc that also used the "People" child tag.

So then, one might ask, what is the advantage of using the project hierarchy vs just entering 3 separate stand-alone tags?

1. Once defined, the system could prompt (autocomplete popup) for each child tag as soon as the delimited (dot in this case) is typed.
2. If I search on "tag:Project1." I would expect to find all Notes that contained either the parent, or any of its child tags (forget about having to change options/preferences for this, which we don't have anyway for EN Mac)
3. Automation/Help in entering tags in the Search box
   • I don't always remember all of the tags I have created in a tag hierarchy when I am entering "tag:TagName" in the Search box
   • But I usually remember to top-level, or parent tags
   • So, it would be most helpful if Evernote would display all available child tags for a given parent when I type "Parent."
   • Of course, Evernote could provide this without adding the dot notation that Rob requested.
4. and I'm sure there are other advantages . . .

But, this is all very academic, particularly now that the new Evernote CEO has publicly stated that he's going to fix the Evernote foundation before considering any new features.  And, having a more extensive, robust tag system has been requested for many years, but to no avail.

Personally, I'd rather see Evernote support full boolean search syntax with autocomplete on the Search box before tackling tag improvements.  Just my 2¢.

[DTLow 5,736]

14 hours ago, JMichaelTX said:

A good example might be projects, which most often have a standard set of hierarchical topics, as in:  Project1.Resources.People

I use the separate tags scheme, not child tags
and a script (Mac) for the popup of the standard set of associated tags

A sample project has
- a project master note   tag:!Type-Project, tag:!Project-aaaaa
- people master notes     tag:!Type-People,  tag:?bbbbb,            tag:!Project-aaaaa
- task notes                       tag:!Type-Actionable,                            tag:!Project-aaaaa
- misc notes                      tag:!Type-Reference, tag:!Ref-ccccc,  tag:!Project-aaaaa

>>If I search on "tag:Project1." I would expect to find all Notes that contained either the parent, or any of its child tags

By using a prefix naming standard, child tags are included using search tag:Project1*

[JMichaelTX 4,117]

22 minutes ago, DTLow said:

I use the separate tags standard

We all use that, because that is all that is available to assign or search for Notes (other than for EN Win Options).

I make considerable use of the tag hierarchies to provide:

1. Organization of related tags
2. Easy selection in the Tag Filter and Tag assignment fields
   1. For example, all of my stock symbols are child tags of "Symbols"
   2. But I have to use a prefix naming convention of "SYM.<symbol>" so I can type "sym." and get a picklist
   3. This is where @Rob Freundlich's request would be very useful.
   4. It would eliminate the need for prefixes

3. Using Tags as Pseudo Notebooks (pNB) 

[CalS 5,280]

14 hours ago, JMichaelTX said:

Personally, I'd rather see Evernote support full boolean search syntax with autocomplete on the Search box before tackling tag improvements.

Amen.

[DTLow 5,736]

19 hours ago, JMichaelTX said:

• For example, all of my stock symbols are child tags of "Symbols"
• But I have to use a prefix naming convention of "SYM.<symbol>" so I can type "sym." and get a picklist

I do the same thing; prefixing the tag names in parallel with the hierarchy
It's much more workable that tags are anchored instead of floating randomly in the taglist.

My top level prefixes are ? ! @ . (?Who, !What, @Where, .When)
and some of my collections are:
     !Budget-aaaaa (Budget Categories)
     !Project-aaaaa (Projects)
     !Ref-aaaaa (Reference)
     !Type-aaaaa (Note Types)
     ???Dr-aaaaa (Doctors)
     ???Vndr-aaaaa (Vendors)
     ??aaaaa (Persons - Family Members)
     ?aaaaa   (Persons - Miscellaneous)

For archiving obsolete tags, I prefix the aaaaa description with "x"
It doesn't remove the entry, but it sorts to the bottom and can be more easily ignored