[Feature Request] Nested tags

[woodwm]

Obsidian supports nested tags using #inbox/to-read. Nested tags can replace folders to show hierarchy relationship.

[Mrz-zz]

I think the feature is really necessary, support this idea!

[GeoffreyChen777]

That's interesting. I want to discuss more about your design:

1. Suppose I have a Paper C, it is a multi-modal segmentation paper. So I should have tags like:
   Paper C: multi-modal/segmentation.
   When dealing with tags, is the segmentation under multi-modal identical to the one under cv?

2. In the database, we store something like:

{
  name: cv
  ...
}

{
  name: cv/segmentation
  ...
}

or we store:

{
  name: cv
  ...
}

{
  name: segmentation
  ...
}

i.e., the atomicity should be kept only in UI or in both UI and database?

I think, for folders, your solution is really good. Because two subfolders under two different parent folders should be treated as two identities even if they have exactly the same name.

But for tags, I think due to the atomicity, they should not be treated as two identities. The segmentation tag should be considered the same whether it is in hyper-tag A (e.g., cv) or hyper-tag B. (e.g., multi-modal). If we store the tags like this:

{
  name: cv/segmentation 
  ...
}

, when we want to find papers related to only segmentation, the database need to give me the results with tags like:

{
  name: segmentation    ✅
  ...
}

{
  name: cv/segmentation     ✅
  ...
}

{
  name: multi-modal/segmentation     ✅
  ...
}

{
  name: cv/classification     ❌
  ...
}

It means that in the database, we have no atomicity right?

[GeoffreyChen777]

[charlieJ107]

I agree that by creating a new table to store complex tag or folder relationships, user-defined smart filters can also be converted into such tag relationship entries. When querying, first generate query conditions based on tag or folder relationships, and then use these query conditions to query the database. This can preserve the atomicity of storage in the database.

In fact, this is equivalent to abandoning the original concept of folders. Folders are regarded as a special label. The so-called nested relationship between folders and labels becomes an AND logic between labels. I'm not sure whether we should embody this concept in the UI from a user experience perspective. For example, we can simply remove the concept of folders.

[GeoffreyChen777]

Hi, let's discuss it from three aspects: User Aspect (UI), Design Aspect, and Implementation Aspect.

User Aspect

I think the UI design I discussed with @fkcptlst is good, i.e., we have two modes for the left sidebar panel:

• Flat Mode: just like what we have in the current version.
• Hierarchy Mode: show a tree

For folders, previously I just used it for the link-to-folder feature of the quick-paste plugin (the window shown when we press cmd+shift+I. For user-friendly, I think at least we need to keep the tag concept as it is very intuitive.

I agree that we need to reconsider the categorizer/label system in Paperlib.

Design Aspect

In this section, I will propose a new design for the categorizer/label system in Paperlib.

Basically, in the current Paperlib, we have three concepts related to categorizers:

• tag
• folder
• smartfilter

The first two are user-defined properties of a paper. The third one is a complex query sentence.

So if we decide to change the database structure, we can modify the PaperEntity model like this:

interface PaperEntity {
  title: string;
  authors: string;
  ...
  userProps: {
    tags: string[]
    folders: string[]
  };
  ...
}

We can use userProps.tags and userProps.folders to represent the first two concepts. And we only store their names. About the colour, I will discuss it later. Here we also have the possibility to add more user-preferred properties in the future.

In the following, I ignore userProps for simplicity: paper.tags paper.folders.

In the sidebar panel, previously we have three sections: Smart Filters, Tags and Folders. As they are all real models in the database, we just show them directly.

However, each row in the sidebar panel can be regarded as a query sentence:

• tag: A query sentence for the corresponding tag, such as tags.name == 'Tag1'
• folder: A query sentence for the corresponding folder, such as folder.name == 'Folder1'
• smartfilter A complex query, such as tags.name == 'Tag1' and folders.name == 'Folder1'

As you mentioned that you think we can use a graph for the relationships between categorizers, what about we regard query sentence as nodes in a graph. The edge between two nodes indicates how we combine them. By doing so, we can achieve the nested tags/folders, and most importantly abstract tags, folders, and smartfilters into a single concept.

Graph

It should be a directed graph.

Node

The Node structure consists of three main properties: Name, Self Query, and In Edge Logic (I just ignore the id for simplicity):

• Name: indicates the string we show in the UI.
• Self Query: is the query sentence of this node.
• In Edge Logic: indicates how to combine the queries of those nodes pointing to this node.

So in a graph. We have three kinds of nodes:

They are just for explanation. In the implementation/database, we can use one class/model for them.

• Logic Node: contains no self-query (true). Just use it for node combining.
• Query Node: contains a query sentence. But it will never gather and combine the query sentences of the nodes pointing to this node, as its In Edge Logic is just a true
• Mix Node: mixture of the above two types.

Graph for Nested Tags

Suppose we have three tags as shown in the figure, in the graph, we should have three Query Nodes. In addition, we have a ROOT Node Tags. That is the one shown here:

The nested structure is represented by the topology.

As the tags concept in Paperlib is atomic, we can easily transform them into a simple query sentence like 'xxx' in paper.tags

If the user prefers the Flat Mode, we can just get the entire graph connected with the Tags ROOT Node and flat it to show.

If the user prefers the Hierarchy Mode, we can transform this graph into a tree and show it in the UI:

Here we can see that the In Edge Logic of all nodes in this graph is just true. This is due to the way we create the final query when users click a tag in the sidebar.

Generate the final query from a graph

Suppose now we click the cv tag (Query Node 1) in the sidebar. The results we want should be all papers related to cv. We don't care about the fine-grained research topics. Even a paper containing only a single cv tag should be included.

To generate the final query from a graph, in this case, we start from the Query Node1:

• We first get the Self Query of this node. Now we have 'cv' in paper.tags.
• Next, we iteratively go to the upper-level node until the ROOT Node, get all queries in these nodes and combine them with AND. Now we have 'cv' in paper.tags AND true
• Next we aggregate the lower-level node according to the In Edge Logic. If it is a string with some placeholders such as $1 OR $2, we collect corresponding queries. If it is just a true, we will not collect the queries of the bottom-level nodes. We finally combine the queries we collected with the previous one with AND, now we have: 'cv' in paper.tags AND true AND true.
  'cv' in paper.tags AND true AND true is the final query we should use to filter the database when we click the cv tag.

If we click the segmentation tag under the cv tag, we should have a final query like this:

'segmentation' in paper.tags AND 'cv' in paper.tags AND true AND true

It will give us the desired results: papers related to segmentation and cv.

For AND true, we can simply ignore it in implementation.

Graph for Smart Filters

For smart filters, we can also represent them as a graph. I basically have two designs, I really don't know which one is better:

Design 1

The ROOT node is used to get the graph related to smart filters. We will also show it as a section in the sidebar.

Suppose we have two kinds of smart filters: a nested one (last two years), and a single one (cv paper by Author A).

For the nested one, we create a tree as shown in the figure. The main difference with the tree for tags is that, some In Edge Logic is a rule string, not a true. It will help us to generate the correct final query.

For example, when we click last two years - Author A in the sidebar (Mix Node 2 in the graph), we want to get the papers written by Author A, and in the recent two years, and only related to optimisation and segmentation. That is different from what we want in tags. In tags, we don't care about the lower-level node by using a true as the In Edge Logic. But in a smart filter, I think we should care about the lower-level node. We may only want to use this smart filter to find papers about two topics written by Author A. Author A may have other papers in our library, but we don't care about them in this smart filter.

Thus, we need to modify the In Edge Logic to $0 OR $1. By performing the process I described above, we can have a final query: paper.authors contains 'Author A' AND (paper.pubTime == 2024 OR paper.PubTime == 2023) AND ('segmentation' in paper.tags OR 'optimisation' in paper.tags).

If a user wants to create a single complex smart filter, we can create a node likeQuery Node 1.

Design 2

This design is similar to what we do for tags. It means that all In Edge Logic is just a single true. When we click last two years of AB - Author A, we get all papers written by Author A in the last two years. We don't care about the lower-level nodes here.

---

I really don't know which one is better. Maybe we should keep both of them and make it configurable?

Folders

For folders, it's similar to tags, but with a different ROOT Node.

I just realised that folders are totally different.

| -- Folder A
    | -- abc
| -- Folder B
    | -- abc

Because these two abc under different parent folders are totally different in a file system. It means that the real name of abc is Folder A/abc, not simply abc as we have in a tag system.

So we probably need to store xxx/yyy as the name of each folder.

Colours

We have different colours for tags/folders/smartfilters. In the new design, we store the colour attribute in each node.

---

By doing so, we can use graphs to represent the concept we used in Paperlib and their relationship in a uniform way. And we still have the atomicity.

Users may create their own ROOT node rather than the basic Tags / Folders / Smart Filters.

Implementation Aspect

1. I need to investigate the database to see how to store the relationship between objects.
2. Implement a tree view for the sidebar.
3. Create a function to generate the final query according to a Graph and the starting Node.
4. We need to design an easy-to-use UI for users to create Node and Graph. For users, they should not access/understand the concept of Node and Graph. They should just feel like they are creating hierarchical tags / folders / smartfilters. Most importantly, it should be a top-to-bottom creation.
5. How to count the number of papers related to a node is a problem.

[GeoffreyChen777]

@charlieJ107 I have implemented a demo for the proposed graph-based-filtering-system:

https://github.com/Future-Scholars/demo-graph-based-filter

It looks good.

But I found some limitations of database model design.

Realm doesn't support define model like this:

interface Paper {
  title: string;
  ...
  userProps: {
    tag: string[]
  };
}

I have no choice but to define it like this:

interface Paper {
  title: string;
  ...
  userProps: UserProp[];
}

interface UserProp {
  key: string;
  value: any[]
}

However, the query sentence for tags/folders looks very complex:

SUBQUERY(userProps, $item, $item.key == 'tags' AND 'optimisation' in $item.value).@count > 0

We need to find a better way for this.

The graph-based query generation looks good.

[GeoffreyChen777]

For db implementation, I think storing cv/segmentation would suffice (it is not so pretty since it sacrifices the atomicity of data table, but it gets the job done).

Or you can create a new table to store the hierarchy alone. The advantage of this method is that it does not break the process logic of original tags. The tags table can maintain its atomicity.

@fkcptlst So now I understand your design:

• For design/concept aspect, tags should be atomic.
• For database:
  • we store hierarchical names like cv/segmentation. If the user also has a top-level tag segmentation, or a child-tag under a different hyper-tag such as multi-modal/segmentation, we store all of them in the database. Consequently, in this case, we have 3 objects in the database, but in the top-level design aspect, they indicate the same concept.
• For UI:
  • In the right details panel, main table view, tags should be shown in an atomic way like what we have now: cv, segmentation
  • In the left sidebar panel, it depends on the user preference. We should have two modes:
    • Flat Mode: just like what we have in the current version.
    • Hierarchy Mode: show a tree rendered according to the hierarchy name
• For querying:
  • In the Flat Mode, if a user wants to show all papers related to a tag such as segmentation, the filtered results should be those with tags segmentation or cv/segmentation or multi-modal/segmentation
  • In the Hierarchy Mode, we just show the results with the exact hierarchy tags.

Pls correct me if I'm wrong.

[woodwm]

Hi, the discussion is quite long. Let me explain what I think of the usage and design of nested tag.

I found a good reason of using nested tag in Evernote,

If you have a lot of tags in Evernote, you can organize them by creating nested tags. Nested tags are tags that are organized as sub-tags under a main tag. With nested tags, there is a main tag and one or more sub-tags. For example, a main tag "Travel" might have multiple sub-tags "Chicago," "New York," and "San Francisco."

This is a good and clear explaination of nested tag which is used to organize tags. Considering this, we are ready to think about cv/segmentation and multi-modal/segmentation. Does the segmentation in the two nested tags the same or not? My answer is no. The only common part is the name, but they refer to different concepts. The same applies to misc in notes/misc, supplement/misc. If we agree that they are different, their tag need to be different.

This can be done by define a UUID for each tag. Tag has the property of name. A new object nested_tag is a instance of tag, but has addtional property of parient tag and child tag. nested_tag is more general than tag, as normal tag can be considered as a nested tag with no parient tag and child tag which is a top-level tag. cv/segmentation is a nested tag with two nested tag objects cv and segmentation. segmentation in cv and multi-modal are different objects with different UUIDs but the same name.

The good point of this design is that when the user add a tag segmentation to a paper, we can provide suggestions to allow it to choose which segmentation the user refers to and select either cv/segmentation or multi-modal/segmentation and complete the other parts for the user.

In this concept, the Flat Mode does not make sense as the conflict in tag name. The nested tag becomes first cityzen. We can still show all papers that have segmentation tag by using smartfilter.

[woodwm]

No. I did not break the atomicity of tags. In my post,

cv/segmentation is a nested tag with two nested tag objects cv and segmentation.

Let me rename nested tag object as nested tag component. Every tag or nested tag are composed by nested tag component which includes the property of parient tag and child tag.

The only difference is that I think the tag component in different nested tags are different object with different UUID but the same tag name. misc does not require another tag note or supplement to differtiate with each other. As the UUID is hidden from the users, this means when the user add a tag misc to a paper, it is unclear which misc he refer to. Thus, the software need to provide suggestions (by searching in the tag component table) to allow the user to select note\misc or supplement\misc, and add the corresponding other part automatically. This process ensures the correctness of tag system.

When tags in different nested tag are the same, they can only be differentiat by its upper level tag. When we have 20 or 30 tags, it becomes a budden to maintain the tag system. You will always find that some papers missed some tags and then the nested tag is not correct. (This happens to me using Zotero. ) Eventually, every paper needs to have many tags to support the correct nested tag.

Both approach works and can show the same result with different approaches. No right or wrong, but different using patterns. I think taking tag component different in different tags is more easy to maitain the tag system. Potentially, I think it is also easy to search in the tree for a certain tag.

[charlieJ107]

Let me try to describe such a usage pain point to see if I understand why you want nested tags. When we collect a new paper, we may have some tags in mind, such as misc, segmentation, but forget to add other tags. For example, although we added the segmentation tag to a paper, because I did not Adding either of the two tags cv or multi-modal will cause me to not know whether this paper is a segmentation in a cv context or a segmentation in a multi-modal context when I search in the future. Based on such a usage pain point, you want to introduce nested tag, and when the user tries to add a tag named segmentation, force the user to choose one of cv or multi-modal, and ensure that these papers identify the segmentation tag. It must be represented by one of the two tags cv or multi-modal. Is this a mechanism you want?

[GeoffreyChen777]

Here we just talk about user aspect design. For implementation, please refer to #354 (reply in thread). We are designing a graph-based implementation, and we can use a graph to generate the final query for the database. It is the work for our teams because users may know nothing about coding.

For user aspect. What we should discuss are:

• what do we want to see in the sidebar tree?
• what do we want to see in the details panel?
• how to add new tags?

What do we want to see in the sidebar tree?

I just have one question.

| -- Travel
    | -- New York
    | -- Chicago
| -- Tasty
    | -- New York
    | -- Beijing
    | -- Tokyo
    | -- ...
| -- New York 

When I click the top-level tag New York, do you want to get the results including things under Travel/New York and Tasty/New York?

If your answer is yes. Then you should realise that these three tags are identical. Because they represent the same thing: "New York related". They are at different positions of the tree. The position only indicates if there are any additional conditions. The postion will never change the meaning of this tag itself. Don't consider the code implementation, just from user experience.
If your answer is no. Then what you want is a file/folder system, not a tag system. Please understand what is folder and what is tag.

what do we want to see in the details panel?

In the details panel, which one do you want to see?

• Travel / New York. : a single nested tag string
• Travel New York : atomic tag string.

If you choose the first one, then you want a file/folder system. Because tags should be atomic, Travel / New York can be split into two tags, which breaks the atomicity.

how to add new tags?

when we open the editing view. we have an input box. If we type New York and then directly press Enter, it means that we assign the top-level New York. if we type Travel/New York and press Enter, it means that we what to assign two atomic tags: Travel and New York, and specifically, it should be the New York under Travel. However this New York is the same as the top-level New York. The main difference is that they are two copies of the same object/concept at different positions in the tree. The position only indicates that how to filter the database. The position of a tag in a tree will never change its meaning. The New York tag at anywhere always represents "New York related". So we just keep one single object in the database.

---

I think what you want is a file/folder system, not a tag system. Anyway, you can use a folder system as a 'tag' system, it depends on you.

[GeoffreyChen777]

@woodwm Hi, as you mentioned the tag system in Obsidian, I tried it and understand how they design their tag system.

Basically, it's a folder system and has no atomicity. I.e., New York is different from Travel/New York.

In the current version, we have tags, folders, and smartfilters. In Paperlib's next step, we will still have a folder system, but is nested. Compared with the file system in an OS, here the folder system allows you to link a paper to multiple folders without copying the source file. That would give you an exactly similar experience with Obsidian's tag system.

For the next steps of tag system and smartfilter system, how to design it would not change your usage preference with the help of the nested folder system.

Thanks for all of your constructive comments and have a good weekend.

[woodwm]

Both designs should work. Users will choose what is best suitable for him/her. Please go ahead in your plan. Thanks.

[GeoffreyChen777]

Hi @woodwm @fkcptlst

I've implemented the nested folders and even smartfilters #360. The code has been merged into the dev-3.0 branch and this feature will be released with the next 3.0 beta version.

Thanks again for your constructive comments. Now I'm closing this discussion.