List neighbor pages

Migrated from github#450
I know the below feature proposal is just one implementation to the problem on the header. Should I split this feature request to two, @tienson? One for neighbor node display and one for the generic header/footer injection?

Is your feature request related to a problem? Please describe.
My main goal is to list neighbor pages.

Consider the following page graph:

When viewing page b, I’d like to have a panel stating:

  • Also links to t1:
    • c
  • Also links to t2:
    • a

Describe the solution you’d like
I’d like to have a hook, which injects arbitrary content (including queries) to any page header/footer.

Describe alternatives you’ve considered
¯\_(ツ)_/¯

Very interesting idea. Having custom queries for all pages (besides backlink references) like in Journals can be a killer feature. This can extended what can be done.
Of course those queries dont get inserted in the pages (markdown) like backlink references queries.
I’m thinking of queries that show blocks of other pages with a timestamp showed when the page you are viewing have a timestamp or some block with a timestamp and the year is the same.
Or creating more advanced relations between blocks or pages (like complex namespaces, etc…) as backlink references (I mean here extending the actual backlink references internal working).

1 Like

Can you define “neighbor nodes” and “neighbor pages”? Are these just items that the page links to? Does it include backlinks (links with the current page as target)? Or are these any page/node that links to a page/node the current page links to? If the latter, can’t you get this information by going to the target page and checking the backlinks?

1 Like

I used pages and nodes as synonyms. Page a and page b are neighbor pages if there exists a third page (here page t1) to where a link exists both from page a and b.

So, taking the figure in the original post, page s a and c are not neighbor pages.

If I understand you, for pages A, B, and C, if A links to C and B links to C, then A and B are neighbor pages.

In this case, if you want to see what links to C, you can go to page C and A and B will both be listed as backlinks. I understand that you want to see B listed on page A as a neighbor, but I wonder about the actual use case. For my notes, with relatively long pages with lots of interlinking, I’m pretty sure such a list of neighbor links would become overwhelming. I’ve nothing against the idea, just wondering if it adds significant functionality. Also, where would you want this list presented on the page?

Use case: instead of tagging (#tag), I would just link to the page ([[tag]]). That way simplifying the model (no special handling for tags).

Yes, the list may get huge. But OTOH if your page has more than one outgoing links, iterating them by hand would be also tedious.

Where presented: no idea, perhaps at the bottom of the page (right where the Unlinked mentions rendered now)

Again, no objection to the idea, but #tag will still be supported, so it doesn’t simplify Logseq as a program, and users can still use [[tag]], and you can still click on [[tag]] to see page tag and see all links to that page. So it seems to me to be something that can be done with a plug-in at some point.

I think it would be more accurate to refer to ‘indirect links’ or ‘indirect connections’ rather than ‘neighbors’ (in graph theory, neighbors are actually nodes sharing an edge).

it can be really useful to trace the ‘path’ between nodes (pages), take :
a <- > b <-> c
here, ‘a’ and ‘c’ are indirect links, going through b.
Think of it in terms of social network : Albert knows Bernard, Bernard knows Charles, so Bernard can introduce Albert to Charles.
(related link: 2.5 Indirect Connections:Basic Concepts | Social Networks: An Introduction)

imo, this should be solved via the ‘page graph view’ by enabling a ‘depth level’ slider (obsidian terminology) : the level of indirect links that you want to show.

see the related feature request with a gif of obsidian’s page graph : Graph view : add depth levels adjustment

nb: Obsidian, Siyuan Notes and Athens provide a similar feature in their page grph view.

2 Likes

Why not call them siblings? (tree, directed graphs)

Please no! It is a directed graph (links are not commutative, like friendship):
a <- b -> c

a and c are siblings. Can you live with that terminology?

Oh no, I cannot edit the title of the feature request :frowning:

My plan was not to remove tagging. I just would like to demonstrate my usage pattern. If anyone interested in that, look up the (already abadoned) piggydb, oinker (demonstrative video)and cotoami.

Wait a minute there! “Sibling” is an important term already in use that refers to list items or blocks at the same level as each other. It is a descriptor in contrast to “parent” and “child”.

A
—B
—C

A is the parent, B and C are siblings, and B is A’s child.

Yes, it is the very same concept, but applied for pages.

Unfortunately in Roam and others there are two different terms for items (page and block), where in RemNote everyting is a rem.

But it’s not the same concept, is it? Two pages that link to a common 3rd page are not both children of the same parent. But sibling blocks are both children of the same parent block.

Yes they are. If you see tags as parent pages, tagged pages reference them like parents. But yes, the analogy is not perfect, because you can link not just tag pages but also “normal pages”.

Ok, so the taxonomy is not clear, but I’d like the “pages that also link to pages where the current page links” functionality as seen in scrapbox.io.