How to leverage Logseq's linked structure?

Questions & Help
41
  • underconnected:
    • have less than 2 connections
      • they should either:
        • acquire more connections
        • be merged into other pages
  • overconnected:
    • have more than 8 connections
      • they should remove some connections by either:
        • delegating them to the remaining ones
        • breaking into smaller pages

I’ve read through a number of your discussions across the forums here and have greatly appreciated the insights and recommendations for how best to utilize Logseq’s functionalities. I’m just beginning my journey of shifting notes into the Logseq ecosystem and I wanted to avoid making too grievous of errors while pulling data in.

image
image689×955 46 KB

This is my nascent graph; already I can see where there is likely going to be some connection bloat in tagging every family member, friend, and coworker as a person - but I was curious on how you would suggest to balance providing metadata to relevant objects without needlessly trying to capture “all reality” as you put earlier in this thread.

I could see excessive noise in how tagging all instances of a person to “people” generates meaningless noise. I considered simply keeping friends and family without a connection as I don’t intend to allow overlap. In instances like this, how do you decide to effectively restrict connections between objects?

I hesitated to remove the people connection in case I wanted to use some tricky queries down the road for coworkers who became friends or something silly that could use the high-level connection of a people tag.

I appreciate any and all thoughts as I kick-off my journey!

P.S.: The tech/kub cluster is just being written, so I’ll have to ask forgiveness for their lack of interlinking.

43
  • Use tags:
    • not for meta-data
      • e.g. don’t tag a person as #family
      • For meta-data, use properties.
        • e.g. add to a person a property family:: my family
          • Could still decide to hide family from the graph.
            • Through property exclude-from-graph-view:: true
    • but for connections
      • i.e. for associations
        • e.g. [[Person1]] is a #friend of [[Person2]]
          • Could still avoid some references depending on which page this note is placed.
  • Don’t use generic tags (e.g. people) when already using specific ones (relative, friend, colleague etc.)
    • To each specific tag, add a page-property like type:: person
      • That is enough for queries to relatively easily consider all persons when needed.
1 Like
44

thank you for the quick response and thoughts! i misspoke (miswrote?) to say i was using #tags/tag pages. i was using page properties in the form of tags:: people to generate the connections between nodes. a point of confusion for me is that i’m not sure what the inherent difference is between a #tag/[[tag]] and a page property tags:: tagName in how logseq associates nodes.

My understanding is that tags are external/soft associations vs the “hard” association from an in-line reference. The result for either is that the association is created between the two pages that hard/soft tag lies in. As the page property tag does much the same (i suppose in a ‘hard’ manner since it is explicitly written as a property?), i’m not sure what distinction would bear out between the two.

As an aside, i’m curious on your thoughts for how the class-based/supertags detailed in the new db version documentation will play out into this approach

45
  • The properties I refer to are not tags.
    • For example, in type:: person the value “person” is taken:
      • as a plain string
        • It is available to queries.
      • not as a reference/connection/association to page person
        • It doesn’t affect the Graph view.
  • The role of tags in the DB version has not been clear-enough so far, thus too early for making any thoughts.
    • But properties’ role gets upgraded for sure.
1 Like
46

This is excellent summary