Three power-tools I wish I'd known about when I started using Logseq

  1. Templates: quickly add custom text to any page with a the /template command.

  2. Aliases: give an alternative name (or names) to any page. If you have a contact named [[Samuel Clemens]] you can create an alias for “Mark Twain” and both will point to the same page.

  3. Page-tags: there is normally no difference between #tags and [[pages]] in logseq, but there is a separate category of tags called “page-tags” which can be added as a top-level property to pages. Just enter tags:: tag1, tag2, etc. on the first block of a page (along with the alias and any other page level properties you might want to define yourself).

    • There isn’t much documentation about these, but if you add them they show up in a special section on the page for that tag. You can also query them using {{query (page-tags [[tag]])}}.
    • I use this to add a second level of organization to pages when I have a lot related to a specific domain: contacts, books, etc. I then add additional tags to further aid in querying. For instance, I might add “business” or “person” to contact pages, and “fiction” or “nonfiction” to book pages.

Addition to third point.

  1. Page:tags:
    • tags:: tag1, tag2 is equivalent to tags:: [[tag1]], [[tag2]]. Logseq automatically tag/link up those keywords. Hence, a block {{query [[tag1]]}} will also find page tags:: tag1.
9 Likes

Thank you very much for this @Luhmann very helpful.

Could you please explain 2. Aliases and 3. Page-tags bit more. Is there any real-life note could you share with these features?

Sorry I can’t provide any more beyond the links I’ve already included above, but I have seen that some people have offered step-by-step youtube instructions on some of these features. You might look for those.

Also see this other post about my workflow: My Logseq Workflow

1 Like

Page tags have an annoying quirk in that references are shown twice: first for “Pages tagged with” then for “Linked references”.

3 Likes

To be clear would your (@Luhmann) second level of organization schema work using block-level property tags instead of page-level property tags?

For example:

Page for a topic

  • [[topic of interest related to page]]
    tags:: tag1, tag2, tag3
    • some child note about topic of interest related to page

And what happens if there are page properties and block properties??
For example:

Page for a topic

tags:: page property tag 1, page property tag 2, etc.

  • [[topic of interest related to page]]
    tags:: block property tag1, block property tag2, block property tag3
    • some child note about topic of interest related to page

I’m having a hard time wrapping my head around this, any insight or guidance would be much appreciated…sort of terrified of my graph becoming a huge tangled ball of wires.

1 Like

You can mix page tags and block tags, but for simplicity it helps to be consistent - using certain types of tags for one and different types of tags for the other. My page tags tend to be more about categorizing the type of page, while my block tags are more keywords and related ideas. But it shouldn’t matter too much.

“terrified of my graph becoming a huge tangled ball of wires.” - I’d recommend starting slow and only adding new levels of organization (including tags) as needed.

1 Like

Thank you for your reply! To clarify, the page properties don’t necessarilly get inherited by the block properties? Part of the reason that this is more confusing for me is that I don’t yet have a handle on using queries effectively.

1 Like

When you query for page properties, you will only get page properties. However, I think there are other kinds of queries you can do that might show both. You’d need to ask someone better at query language.

1 Like

Yeah, I noticed this, and was confused. On a page, in the uppermost, first block, I type tags:: #second-brain. Then, I escape-out of the block. And logsec renders what I typed (which is #second-brain) without a hashtag! (that is, second-brain). To add further to my confusion (due to UX inconsistency in logseq’s part) I could click on the second-brain, even though it doesn’t have a hashtag in front of it, nor is it enclosed by double square-brackets!!

1 Like

Is there a difference between block tags, and the #hashtag entries that one enters at the end of a block? Functionally speaking, both seem like associating a term with the block itself. So, why would one go the extra button-presses in order to insert a block property tag (first shift enter at the end of a block, then type tags:: , and then enter your actual tag) while one can simply input #hashtag directly at the end of a block?

Mostly just to have some visual separation between the text and the tags. Using something like the Awesome Props plugin you can even keep your block properties (including tags) completely hidden.