Specify and display relations between pages/tags

Feedback Feature Requests
1

Premise

Following the discussion here I think I have a viable and concise proposal to address most use cases of the “hierarchically organize pages/tags”.

The point is specifying hierarchies using page properties.

For me the ideal would some syntax that, given an arbitrary user-defined <property>, (for example extends::), looks like this:

Specify relations between pages

Parent.md
<property>:: [[Child]]

:arrow_up_down:

Child.md
<property>:: [[Teddy]]

Display these relations

Tree

{{tree <property>}}

displays an indented list of pages by following that <property> specified by the user, i.e.

- [[Parent]]
  - [[Child]]
      - [[Teddy]]

Reverse tree

{{reverse-tree <property>}}

display another indented list but by following <property> in the other direction:

- [[Teddy]]
  - [[Child]]
      - [[Parent]

Breadcrumb

{{breadcrumb <property>}}

used in a page involved in the hierarchy above, for example Child.md, displays:

[[Parent]] > [[Child]] > [[Teddy]]

in case Child.md is involved in a more complex hierarchy it would be:

[[Parent 1]] > [[Child]] > [[Teddy 1]]
                         > [[Teddy 2]]
[[Parent 2]] > [[Child]] > [[Teddy 1]]
                         > [[Teddy 2]]

Reverse breadcrumb

(you got the idea)

Graph view

In addition it would be nice to display in the graph view only certain relations and not other ones (including “reference” that is the only type of relation we have now in the graph view).

For me it would be also useful to display the graph directly on a page with the command:

{{graph <property>}}

and for the graph of the current page only (like the one we already have in the sidebar):

{{page-graph <property>}}

CC @gax @boisjere

2

So then the specific thing Logseq devs would have to add are the reserved “tree” and “reverse-tree” queries, as well as “breadcrumb” and “reverse-breadcrumb” queries, such that they recursively fetch and display all the page links that fall along each branch of the hierarchy, right?

It seems to me that you’re saying we can do much of this already, except that transitive crawling of implied, property based “links”.

1 Like
3

Sounds they are really achievable with the existing UI components.
Happy to see PR on this.

2 Likes
4

While I understand where you are coming from I would like to generally object against normalising using page properties(*) for modelling relationships in the graph. As for why please see Knowledge Management for Tags / Tag Hierarchies - #21 by brsma

(*) Assuming that we stay limited to storing page properties out of context as key/value table in the header

5

@Prote would you be happy with this proposal of mine but adapted to display a file manager-like UI instead of lists, breadcrumbs etc?

The workflow would be the following:

  • type somewhere {{folders my-property-key}}
  • if no page has property-key:
    • show only a + button
    • press + to display a text box, type a page name and select it from the dropdown menu
      • Logseq adds to that page a my-property-key:: with no value
  • else show pages that already have that empty property
  • add another page the same way
  • drag and drop Page 2 on Page 1
    • Logseq adds my-property-key:: [[Page 1]] to Page 1
  • now Page 1 looks like a folder
  • when you click on Page 1, instead of opening that page, the view is updated to show the content of Page 1 as a folder, i.e. Page 2
  • when Page 1 is open as a folder there is button to open it as a normal page and see its content as a page
  • when Page 1 is open as a folder there is still a + button to add other pages and an icon to move up a level (drag other pages there to move them up a level)

The advantage is that you can create as many hierarchies you want and each page can be linked to more than one page per property:

my-property-key-1:: [[Page 1]], [[Page B]]
my-property-key-2:: [[Page X]], [[Page Y]]

And the same key could be used with {{tree ...}}, {{breadcrumb ...}} and {{graph ...}} discussed above for a different visualization.

6

This is great. Sometimes hierarchy makes more sense to me. When you have a data that is in a structured form, having a hierarchy to navigate makes more sense, instead of writing only in a journal page.

If we see, Page Hierarchy is there already which is shown at the bottom. But making it traversed like a folder structure makes it more accessible and quick.

Here are my points on this:

  • Showing the hierarchy on the left sidebar.
  • Hiding the full paths from the mentions with [[ ]]
  • Instead of directly naming full paths always, using full paths in alias might be a better approach (obviously where same name should not be used in multiple places)
  • If this can be solved with the properties, like path:: notes/banking/myaccount1
1 Like
7

Is there a way to financially support this being implemented?

8

One step to that direction: Generate explicit hierarchy out of properties

1 Like
9

This plugin is very close to this and it works with the favourites in the left sidebar:

Thank you @sethyuan

2 Likes