Tip: Make any compound topic a block, not a page, because links in page titles do not become a linked reference

So, i made a list of “Fiscal Hosts on Open Collective Relevant to Drupal Camps” and was putting it into Logseq.

Realized i would want this topic to be linked to from the Open Collective page.

Making the page title Fiscal Hosts on [[Open Collective]] Relevant to Drupal Camps was obviously goofy, and while the link to Open Collective worked there was no corresponding Linked Reference back to my new page.

This seems to affirm the general sense of those working in Logseq to prefer blocks over pages.

Which to me, to reduce mental overhead, means everything goes in the daily journal. (And perhaps later this block and its children moved into one of the topics it references?)

This still doesn’t feel right for me. Especially when i have a clear topic (albeit a compound one).

But creating a page with a compound topic really does not seem to work in Logseq. “Concept C applied to Organization O” should be the title, and it should show up in the references to both the Concept C page and the Organization O page with all of text written which is why having the first block of the page be something duplicative like “This is about applying [[Concept C]] to [[Organization O]]”, because the next blocks would have to be indented below that to all show up in the linked references as normal.

So unless there is some sort of page metadata that can declare what it should be linked to, multipart topics, where the title of the topic itself should link to one or more pages, need to be done as blocks.

And preslavrachev has a good point that although the Create Page dialog will show matching blocks as well as matching pages when you type in a title, trying to reference something from within a note means knowing if it is a page or a block first.

This part could probably be resolved satisfactorily with a feature request to have [[Starting to type a title]] also show matches for blocks below and swap the whole [[ business out for (( if you choose a block rather than a page.

A couple of quick approaches:

  • a page property (e.g., organization:: [[Open Collective]])
  • The “compounding” in a compound topic could leverage logseq’s strengths and be dynamic
    • e.g., create separate Fiscal Hosts as blocks or pages with properties (type:: Fiscal Host, organization:: [[Open Collective]]) then use a query to collate them all in the page Fiscal Hosts on Open Collective Relevant to Drupal Camps
2 Likes
  • I agree with @etc.
    • Metadata belong to properties.
  • Titles should be linked to, not contain links themselves.
    • I don’t consider the additional complexity justified.
      • Nested links can cause headaches.
  • Titles within a graph should follow conventions that immediately show if they are pages or blocks.
    • Ideally, pages correspond to concepts, and everything else is a block.
1 Like

Ah thank you i was looking for one generic “related” or “linked” property. And had not quite grasped that it takes zero prior setup to define any arbitrary property. And i guess my main problem is i did not find the Properties documentation page because i was searching for “metadata”.

If i am unwilling/unable to define the exact relationship, i now know Logseq has a convenient built-in metadata property: tags.

So:

tags:: Open Collective, Fiscal Hosts

is a very Logseq way of doing what i was thinking.

This will put a ‘Pages tagged with “open collective”’ listing above the general Linked References.

Nothing will put the contents of the tagged (or otherwise property-associated) page on the related page, though, the way a reference in a block with children would, except embedding it manually.

CORRECTION: A query would do it as @etc said, a one-time manual act.

1 Like

@mentaloid Hello.

Does that mean writting down a note about a source you prefer it as a block with nested blocks, and then adding a block property to type or categorize it, if so? We miss the power of Metadata layer templating, here?

  • Sorry, but I don’t understand the question.
    • What is “Metadata layer templating”?
    • How does that relate with what I said about concepts/pages?
  • Every note is made of either:
    • a single block
    • an outline of nested blocks
  • Every block supports metadata as properties.
    • When having an outline, should decide which block/node a property should go to.
  • Templates help adding multiple properties at once.
    • The coming database version will probably make that better with classes.

Sure. Let me comment further below:

1.1. Page or Block properties. Any Data that you add to your data to provide meaning.
1.2. If a Page ideally should be for Concept items (topic, domain, area, activity…), therefore everything else is a block, we should state that a note we write down that is not a “concept” (fleeting, review, feedback, summaries, etc… notes) should be written as a block. Am I wrong?

From that point, what I do when I want to inject a set of inline properties into a block, I use an external text snippet tool (in my case Text Blazer, among many others). For Pages I use the built-in Template feature.

If you know how to use the template feature to inject property sets into a block, let me know.

  • 1.1
    • The main meaning of data should be the content itself.
      • That includes any tag/references in the content.
    • Properties are metadata that provide secondary/additional meaning.
  • 1.2
    • A page is a container of notes.
      • To write a page simply means to pick a name and fill it with notes.
        • Ideally, these names should be concepts.
      • All notes belong to some page.
        • Ideally, all notes belong to the page of their subject-concept.
      • Pages themselves don’t belong to other pages, they belong to the graph.
      • This post explains it more.
    • It is not too hard to add a block from a template and then merge it with the above block.
    • But for arbitrary injection, consider using a macro.
1 Like