It should be possible to assign a notebook to several notebooks. And of course the note should only exist once. If a note is selected, the notebooks with the note should also be displayed. (like tags - they should also be displayed when a note is selected).
This would reduce the number of tags needed - maybe the tags won’t be needed anymore. I have to use many tags (~400) to mark notes. Some people may be satisfied with just a handful of tags, but in my case this is not possible.
Assigning a note to multiple notebooks would also solve the “problem” of nested tags.
And also the Android client would speed up, since it is not necessary to create/display the menu with all tags.
As far as I know, the data model of Joplins can fulfill such a requirement. (m:n instead of 1:n between notebook and note, like between note and tag)
Removing a note from a notebook should only undo the assignment to that notebook. The note is not deleted until the last assignment is removed.
Assigning the same note to multiple notebooks is not an option since it would mean completely changing the architecture of Joplin’s backend and the three Joplin apps.
I think what we need are some better ways to deal with many tags. What’s currently missing? Is it better search? Speed improvements?
A “tag” should be seen as a special kind of “notebook”, just as a “note” can be a “to-do”.
The main problem with the current tag implementation is that a single tag corresponds to a notebook at the highest level. So all tags are at the top position in the menu. Happy scrolling! Also the main menu on Android is full of entries, because every tag is displayed. And that’s the reason why the Android app is slow and unusable for me - unfortunately.
As I mentioned in another thread, it would be nice if the tags were displayed “nested”. A possible solution would be a separator within a tag name like “.” or another (configurable) character.
g.de.bonn would be shown as menu
g with a sub-menu
de with sub-entries
In my opinion, the topic “tag” currently has a low priority in Joplin, although it is the most important feature of a note application.
I'am a professional developer of database frontends.
From my point of view: This is a design-fault.
One advantage of using a database instead of single file
(what some people mean to prefer because lack of database knowledge)
I know from own experiences, changing a database-design in a late stadium is problematicaly - but not impossible.
Maybe You implement a new table note_folders as an Option:
If no entry in table note_folders, then look in column notes.parent_id or vice versa.
New note assignments to books - on the other hand - should be done in the new way, only via entry in note_folders.
Since I discoverd Joplin a few month ago, I've transformed the bulk of my notes (nearly 3 thousend, located mainly in writer/calc docs) programmaticly to it and therefore I'am using Joplin extensively in my job.
I hope, I can help to improve Joplin (did already my first test-plugin) and finding my own solution on this topic.
This is a very powerful feature currently used in Trilium Notes. The developer calls it cloning notes. His wiki explains it well.
Forgive my ignorance, but isn't that the power of using a database, query things at multiple locations? Would you mind elaborating a bit on why this is currently not possible?
I just drop this link here in case it is useful in a chain of thought with regards to "tagging instead of hierarchy". Designing better file organization around tags, not hierarchies
It sounds like what you need here is nested/hierarchical tags rather than multiple notebooks per note.
The former is much easier to implement.
I thinks joplin could improve a lot with use of taxonomy (from wp: the practice and science of categorization or classification based on discrete sets). Something like "cloned" notes as in Trilium Notes would be amazing. Though I'd prefer a link instead of a real clone.
Also from WP "Like In a broader sense, taxonomy also applies to relationship schemes other than parent-child hierarchies, such as network structures. Taxonomies may then include a single child with multi-parents, for example, "Car" might appear with both parents "Vehicle" and "Steel Mechanisms"; to some however, this merely means that 'car' is a part of several different taxonomies."
Should this better be archived with multi-parent notes or nested tags though (or both)?
Thanks for your input Svenn. I do understand that hierarchies are very limiting for regular file systems, but I was hoping that Joplin's relational SQLite database could be leveraged to overcome these limitations.
Roman, how hard would it be to implement intersecting tags with AND operators (similarly to Zotero, Calibe, Qiqqa) as mentioned in this post?
I have no idea. It seems like it'd be mostly UI change as the search API should support such queries already.