The linking of blocks, pages, and whiteboards needs to be a separate thing

When you embed a block or paste its reference inside/under another block, what you get is two things:

  • a first block that has a second block inside/under it and
  • the second block that just has information saying that it is inside/under the first block (linked reference)

The right way is to have the linking of blocks as a separate thing.

It’s doing things the first way that hurts our brains when we’re note-taking. Doing things the first way creates a hierarchy or one-wayness in our minds where there isn’t supposed to be:


image


image


image

By having the linking of blocks as a separate thing we get what’s actually being represented in the graph view (this is how we think anyway):

image
image

Having the linking of blocks as a separate thing also frees each block to be its own thing. There won’t be a “real” hierarchy of blocks. The outline view will simply be used to show hierarchy like, “by the way this block can be viewed as being lower in an arbitrary hierarchy with this other block.”

Also, hyperlinking won’t go away. It just won’t be used to show linked references since that’s what linking is for. It simply brings you from one block to another.

What do you think?

Interesting idea. Not sure if I followed precisely. The ideal for me would be to make all of this configurable according to user preference. For example, I would like to have the option to have whiteboards show hierarchy relations as link-lines, and to make it so that creating a link between items in a whiteboard creates a hierarchy relationship (creates an embed of the one block under the other). Hierarchical relationships are a kind of metadata that can mean different things to different people.

…creating a link between items in a whiteboard creates a hierarchy relationship (creates an embed of the one block under the other)

Yes, it’s like that with also being able to link a block and a page, a block and a whiteboard, a page and a whiteboard.

1 Like

I understand that you can just embed or paste the reference of all of them inside/under all of each other like so:

however this is what it looks like:
4b

which is close to but not exactly like:
image

And that is redundant. If you’re just gonna manually put them inside/under each other then there’s no use for linked references.

Also it will be tedious if one block is linked to multiple blocks. You’re gonna have to embed or paste the reference of all of the blocks inside/under that one block and then you’re gonna have to embed or paste the reference of that one block inside/under all of those blocks. Plus, it’s gonna clutter up the hierarchy of blocks in the outline view.

I don’t necessarily disagree with the feature request in the title of this topic (it depends on its implementation). But I do disagree with the thinking approach:

  • References are rarely mutual. Most often:
    • only one thing references another thing
    • the other thing merely back-references the first thing
  • Here are the typical references in your example:
    • video1.md:
      • This is a video about [[philosophy]].
    • journal:
      • I watched [[video1]] on this date.
  • That doesn’t create a hierarchy, but it does create a chain of specific direction, like in your image:
    image
    • In my opinion, this is exactly how we think:
      • I watched → this video, which is about → philosophy
      • But we can also travel the chain backwards whenever needed.
  • Excessive linking is not good practice.
2 Likes

So how I understand what you’re saying is that you agree that the linking must be a separate thing but there should be an option with regards to the linking? Kinda like how the arrows in the whiteboard, you can choose where the arrows point, either two ways in one direction or two directions. Yeah I agree with that.

  • The option to select how exactly the lines look would generally be welcome.
  • But my objection is with the thinking process:
    • If I choose to make an arrow point to both directions, it doesn’t mean that the two directions are conceptually equivalent.
      • There are things where this is true (e.g. roads).
      • But references are one-way pointers by their nature in the mind.
        • Not by how Logseq happens to implement them.
    • In whiteboards, the meaning of links is left to the user.
    • But in the Graph view, the look of the links should reflect the meaning of the underlying relationships.
      • Currently it doesn’t.
      • Things would be clearer if each link between two nodes acquired a third concept, to describe the exact relationship.
        • A reference is just one of the possible relationships.
        • Properties could play this role.
1 Like

Hmm, I see where we’re not meeting. You’re referring to references which, yes, I agree are one-way.

Thanks to what you’ve said, it’s now clear to me what I’m getting at with this post.

What Logseq needs is a new “linking” feature. Because the reason we’re using something like Logseq is to see the links/connections/relations between objects, thoughts, etc.

Links, connections, and relations are fundamentally two-way/bidirectional. When an object is “related” to a second object, it means that the second object is also, equally, “related” to that first object. Whether that relation is hierarchical or not, they equally have a link/connection/relation to each other. These are what we actually want to see when we’re using apps like Logseq.

The problem lies in that we can only see those links/connections/relations through references which are one-way, as you said.

References should just be a means to travel from one block to the next, not as a way (in this case, the only way) to say that one block is “linked/connected/related” (linked reference) to another block.

edit:

Yes, I agree. Btw I realized that this is what I was getting at in my first post in this forum right here: Can Logseq do relations like in Notion?. Now I was able to articulate it better here thanks to you

1 Like