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 toOpen Collective worked there was no corresponding Linked Reference back to my new page.
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.
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 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
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.
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?
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.
