Introducing NewTags (with examples)

Customization Look what I built
24

After recently reading @Luhmann ‘s very detailed post regarding NewTags in LogseqDB, the significance of this “Re-write” struck me. NewTags has the potential to be the only true competitor to Tana’s Super Tags which in my opinion are incredibly powerful and possibly the new direction in modern note taking / PKM.

Very Solid Implementation.

From what’s described here, LogseqDB’s NewTags have:

- Properties/fields that auto-populate when you tag something

  •  Automatic table views of all tagged items

  •  Relations between NewTags (the contact-to-contact example)

  •  Custom property types (checkbox, mood emoji, etc.)

  •  UI positioning options (like putting checkbox at start of block)

What I’m not sure of or dident see, or missed:

- Inheritance (can one NewTag extend another?)

  •  Calculated/formula fields

  •  Automated workflows/commands beyond basic property population

#Tag vs. [[page]]

This is the big architectural decision that changes everything:

Before (Logseq MD): #tag and [[page]] were the same thing

After (LogseqDB): #tag = structured type, [[page]] = link/reference

This is actually closer to how Tana works - where you have regular page references AND Super Tags as distinct concepts. It’s a breaking change from Logseq’s original philosophy, but necessary to make this work.

Workflows

How @Luhmann used these is very smart.

- The #ck trick: Just adding a checkbox without full task overhead - great for simple checklists

  • Combining NewTags: Using #task + #question together to get both task management AND question tracking. This      suggests you CAN apply multiple NewTags to the same block

  • The #diary + mood emoji: Using UI positioning to make properties feel native rather than metadata-heavy

  • #project as orchestrator: Using it to group notes, contacts, and tasks around a goal

Tradeoff

@Luhmann mentions -

“Compared with Logseq MD, it can be a bit harder to modify your setup after you have started to use it."

This is the tradeoff with structured data. Once you commit to a schema, changing it affects all your existing data. Tana has this same issue.

What’s potentially Missing (That Tana Has)

- Commands/Actions: Tana lets you attach custom commands to Super Tags. Not mentioned here.

  • Complex inheritance chains: The ability to have #employee extend #person extend #entity

  • Calculated fields: Auto-calculating totals, counting related items, etc.

  • Conditional logic: "If X then Y" type automation

These might exist and/or they might be planned for later alphas.

Thoughts

- This is great for the ecosystem: Competition drives innovation drives pricing… etc. If Logseq nails this, it validates the concept and might push Tana to improve too.

  • Logseq has an advantage: Being open-source and local-first means the community can build plugins/extensions on top of NewTags in ways that might not be possible in Tana.

  • The learning curve: The @Luhmann warning about "requiring thought and experimentation" is worth noting. This isn't plug-and-play - you have to architect your own system.

  • The alpha warning: Data loss risk + changing schema = don't use for production. But the fact that @Luhmann IS using it daily suggests it's already pretty functional / stable and might be further along than thought.

Future

If LogseqDB launches with NewTags as a core feature and it’s stable, I believe we’ll see:

- A wave of Tana users experimenting with Logseq (especially those who want local-first/open-source)

  • Other PKM tools scrambling to add similar features

  • Super Tags" (or whatever the name) becoming a standard feature category, like "bidirectional linking" became

This might be the moment where structured outlining goes mainstream beyond just Tana’s niche.

My apologies if this went long. Excited to see the final outcome.

2 Likes
25

TagClass should give the idea

3 Likes
26

Complex inheritance chains: The ability to have #employee extend #person extend #entity

This is an excellent summary, thanks. Note that the above feature is now included in Logseq DB.

27

Thank You very much. Long time fan of your posts.

1 Like
28

hhmmm… use

“After (LogseqDB): #tag = structured type, [[page]] = link/reference”

in your mobile app, with my tiny fingers, and tell me about :-/

29

Would you please give an example how the #overview is used. Thank you.

31

I have actually not been using this tag much since I created it. One reason is that the new Library feature now offers a more structured way to group pages by topic.

(I had to add additional text here because I deleted a post with similar content and without this the forum software will think I’m a bot.)

1 Like
32

Thanks for the intro!

Regarding DB graph. Property choices not available on inherited tag property (Extends) it seems.

I have a question about tag inheritance (Extends) in DB graphs. Here’s a minimal example:

  • I created a tag #PARA that extends #Root Tag.

  • On #PARA, I added a custom text property PARA Status and configured Available choices (e.g. Backlog / Active / On Hold / Done / Archived).

  • I created a tag #Project that extends #PARA.

Issue:

  • If I tag a page with #PARA, the PARA Status field shows the choice picker and works as expected.

  • If I tag a page with #Project (which extends #PARA), the PARA Status field shows only a text input with the placeholder “Set PARA Status”. There’s no dropdown, and typing a value doesn’t work (it won’t accept any input).

Is this expected behavior for inherited properties, or a bug/known limitation? If expected, what’s the recommended way to handle “enum-like” properties (choices) on base tags that are extended by other tags?

33

I come to Logseq for its frictionless note taking, the NewTag is causing so much friction :frowning:

34

Using NewTags is completely optional. If you don’t find them useful, you can continue to use Logseq the same way as the MD version: with traditional [[page links]] instead. That still works. In fact, I recommend not using too many NewTags - best to use them only where there is a real benefit from having database-style properties associated with the tag.

2 Likes
35

Best to discuss this on Discord, or in its own thread.