Thanks for the clarification. I added a note to the text for now. If I have time later I’ll fix it.
2 Likes
Really great, clear write-up @Luhmann! This fills a hole in the available info, and gives guidance even for those of us that are not beginners (I’m still thinking through how I want to use hierarchy).You might consider dropping this on Medium, for those that don’t follow Discord or this site.
4 Likes
Thanks for your great piece of sharing.
Related to what you wrote, I have just discovered that Dendron also implement their tag feature in a similar manner as Logseq
1 Like
Awesome!. In logseq everything is a block. Even pages are special kind of blocks. Therefore, it makes sense that tags are also special blocks
3 Likes
This post is so helpful as I’m establishing my workflow. 
How can I run a query for pages with multiple tags (e.g. querying pages that have both #tag1 and #tag2) ? I can’t find any documentation on this 
1 Like
It you have your tags set as page properties, you can use
{{query (and (page-tags [[tag1]] [[tag2]] ))}}
Here is more documentation about Queries (logseq.com)
Thanks danzu, but I’ve tried that query before and it didn’t work—you can see it’s pulling up pages with either tag1 or tag2, instead of the combination of both tags:
How about (and (page-tags [[tag1]]) (page-tags [[tag2]]) ) ?
5 Likes
It works!! (thought I’d tried that but must have forgotten the paren before “and”)
Thanks Luhmann, really appreciate your help
Nice article! Been Very inspiring to me.
Thx this was the best and shortest intro I found on Logseq. I figured most of this out myself during the last week, but I whisked I haves stumbled across your post to save some time and thinking 
2 Likes
This is an excellent discussion; I appreciate it so much.
The best part of this post are the examples that are actually legible and easy to parse. Tagging someone’s name makes so much sense as a relevant idea.
This is this opposite of the examples that fry my brain: redundant tautologies that repeat themselves! For instance, calling tags “tag”. Maybe I should refer to it as the Buffalo problem.
I have tried reading so many other examples today that quickly dissolve into:
“If you have a page tagged with page-tags, you can create another page that tags pages using page-tag tag page-tag tag page tag1.”
I really hope we can encourage a style guide across this forum for examples that clearly separate out the keyword’s function from the keyword’s example subject.
That is, don’t use “book title” as an example of the title of a book, because it’s difficult to know if you’re creating a category of book titles instead of referring to one specific book. Instead, we should encourage examples like “Pet Sematary” where the title is unique and could only refer to a book. (“Animal Farm” may be a seminal work, but I don’t want it confused with someone working on a farm with animals.)
Perhaps I should make this a separate discussion? Sorry for ranting at the end of your excellent post!
1 Like
Thanks, Luhmann.
Such a cogent explanation.
Hat’s Off.
I’d Have Not Discovered Hierarchies Had I Not Strayed Across This So Thank You.
Thank you for taking the time to explain these options. I am using Logseq since last summer but I did not see things as clearly as you explain it here. 
Ideally there is no distinction between tags and page-tags. A page is a block and tags:: are the tags/links assigned to this top block. tags:: currently works a bit different in comparison to other links/tags.
1 Like
The one I’d recommend against is one graph or multiple. Since there are sufficient tools for segregating knowledge, just use a single graph.
The only exceptions I’d make to this are based on ownership. For example, if you collaborate with a team at work or if work wants your knowledge to be shared and owned by the organization. But if it’s personal, just one graph. It makes managing and moving data simpler.
My workplace doesn’t use Logseq, so I just keep my work ideas/tasks altogether in my one graph.
In theory you can keep some pages shared between people in a subfolder of the graph and use something to sync only that folder. Eventually to avoid conflicts (for example someone else create a page that already exist in the private portion of your graph) you can agree on using a specific namespace for all the pages shared in the team, like [[Team Foo/Page bar]].
I haven’t tried this with other people, if someone manage to do so let me know, especially if using Git 
One thing to note with the journal-centric approach is all the backlinks to a particular tag from various dates in the journal view automatically builds a chronology of blocks referring to the tag. This is very powerful and I use it both at work and home.
Working on tasks or projects etc, I put everything into the journal and I get a timeline with events, meetings, and whatever you put in. And with no cognitive load of having to look up and decide where this and that needs to go.
3 Likes
Just wanted to chime in here and mention that after 2+ years of using logseq I’ve abandoned using the journal pages directly, because I choose to sync my graph with git, and I found using the journal with a distributed git workflow leads to large merge conflicts between different environments’ Logseq instances creating the same conflicting day page.
As a result, each place I use logseq, I have a different logfile (for example, [[Personal/Log/2023/11/26]], [[Work/Log/2023/11/26]] that opens up the page with a tag for that day. That way I can go to the day in the journal and see all the log entries for that day from each environment, but avoid the merge conflicts on syncing.