Confusion about the graph view. What's the point of it if you rely on blocks and journals?

General
, ,
1

I’ve been using Logseq for a couple of years, and I was never able to use the graph view for anything meaningful. There’s a conceptual gap that keeps puzzling me, between how Logseq is intended (or recommended) to be used and what the graph seems to be doing.

I use journal pages for everything, with a typical structure like this:

[[14.07.2024]]
  * #meeting with [[Carla]]
    * She points out that [[John]] is working in [[Project XYZ]]

The #meeting block lives in the journal page. There’s usually no content in any of the other referenced pages (apart from properties). I use the “linked references” section in those pages to filter their mentions. So I can enter the [[John] page and in the references I will see him related to [[Project XYZ]], and even filter all the occurrences where they are both mentioned together. Neat!

So far, it’s a pretty default, Logseq-y workflow, right? I mean, even the name of the app incites you to “log stuff sequentially” in the journal.

BUT.

Enter the graph view, and you will see that…

… it only shows links between pages, not blocks. So, [[Project XYZ]], [[Carla]] and [[John]] will appear as linked to the journal page [[14.07.2024]], but not to each other. How is that helping me understand relations between those pages, which are connected via mentions in blocks?

imagen
imagen787×506 9.73 KB

If this app is intended to be used through linked mentions in journal blocks but the graph does’t show those links, what’s the point of the graph view? As you can see above, I’m not able to tell if those pages are related to each other or just mentioned as separate things in the journal.

My expectation would be to see in the graph a link between [[John]] and [[Project XYZ]], and another (maybe lighter, indirect) link of both of those with [[Carla]], who mentioned them. But for me to see a link between them in the graph view, in reality they would need to be mentioned in the body of their respective pages. And that would entirely defeat the whole journal workflow.

imagen
imagen787×506 31.4 KB

Am I the only one perceiving a clash of workflows and concepts here? Why have the graph show only [[page1]]-to-[[page2]] links when the relations are usually [[page1]]-to-((block))-to-[[page2]]?

Is there something I’m missing?

2 Likes
2
  • The two workflows are indeed independent.
    • Although they can coexist.
  • If the graph was showing indirect links, it would get too noisy even faster than it already gets.
    • This is not obvious in your example, but it becomes when adding more notes.
    • Should still have the option to do that, but it wouldn’t be practical for big graphs.
    • There could be a smarter (or even full custom) way of choosing when to show links in the Graph view.
      • But currently the Graph view misses many other features.
  • If you want to make the most out of the Graph view in its current implementation:
    • move relevant parts from the journal to the page that they actually belong to:
      • e.g. [[John]] is working in [[Project XYZ]] is knowledge and belongs to page John
        • The rest of the note (i.e. the meeting) is information and belongs to the journal.
        • Page Carla is not related to the other two as strongly as the two are related to each-other.
          • Unless some other note establishes a stronger relation.
      • It is fine to initially write some knowledge in the journal.
        • Moving knowledge to the page it belongs to can take place later, when confident about its destination.
    • read How to leverage Logseq’s linked structure?
      • Some tried and tested advice.
      • Plenty of links to further discussion on workflows.
3 Likes