Introducing NewTags (with examples)

WARNING: Logseq DB is still in alpha. Use only at own risk of losing data.

Over the past year, the team behind Logseq has been hard at work on a major re-write of the app. The reasons given for this rewrite are:

  • to fix problems with data loss
  • to allow real-time collaboration (RTC)

But “Logseq DB” (because it is based on a database instead of markdown files as in “Logseq MD”), also has some new tricks up its sleeve. In particular, the way tags and properties work has been completely re-written and is now much more powerful.

At the heart of these new features is what is being called “new tags,” or “NewTags” (as I like to refer to them). These are very similar to “Supertags” in Tana, and I think the web page explaining Supertags is really useful for understanding how and why to use these in Logseq as well:

Use supertags to identify objects in your notes: Examples include #task, #meeting, #trip, #subscription, #person and so on. A good way to check if a supertag is right, is thinking “is a” when adding the tag to a node. A node with the contents “Marisha” is a #person. Oslo is a #city. With an eye for “what things come up in my notes that need to be remembered, organized or actioned”, these are good candidates for a supertag.

Supertags are the beginning of creating collections of objects, like a database: Anything you would make a list, collection or database for, these are good supertag candidates. Each row in a database represents one node. Each column represents the Fields of those nodes.

Supertags give you tools to structure the information of the object: Every time you apply a supertag to an item, it populates with default Fields and Nodes of your choice, to help you organize all important and related information regarding this item. If it is a person, adding a Field for their Phone Number and their Preferred Name might be handy. If it is a todo, you may want a Field with the Due Date. See more under Supertag configuration panel.

The biggest change from Logseq MD is that, while #tag and [[page]] were treated as identical in Logseq MD, they now work very differently. For the past couple of weeks I’ve been using Logseq DB exclusively as my daily driver and I wanted to share my workflows for using NewTags to help other people make the transition when the app is released.

First a warning. Logseq DB is still in “alpha” which means that it isn’t stable enough to be considered “beta,” and the underlying data schema might continue to change. For this reason, you really shouldn’t be doing what I’m doing: using this app for anything other than testing.

How NewTags work

One way to think of NewTags is as templates for properties. You apply the properties to the #tag rather than the [[page]] and when you assign that #tag to a page, it automatically applies a bunch of properties to that tagged page.

So, for instance, if I have a NewTag #contact with the properties phone:: and email::,

then when I tag the page [[John Doe]] with #contact, it will automatically be given those properties as well, which I can fill out like a form, or a database.

That isn’t all. Now, when you go to the NewTag page for #contact, it will automatically create a table showing all the data from each of the pages tagged with that NewTag. In the above example, I will have a table of names with phone numbers and email addresses listed next to them.

This is clearly very powerful. But when and how to use this? The above text from Tana offers some good advice: whenever you want to create a collection of similar objects using NewTags is a good idea. It is not very useful, however, if you just want to link two pages because they share a topic. In that case, regular [[page tags]] are still best.

For instance, if I have a page for the project “write a post about NewTags” I don’t really need to turn that all into a NewTag because there will be only one such project. While I don’t want #write a post about NewTags, that page is a type of “project” and I do have many other kinds of projects, so it does make sense to add #project to that page. (See more about how I use this below.)

Finally, you can also link NewTags together via properties. For instance, if you have a #contact NewTag, you can create a relations:: property for #contact which allows you to link that person to their relatives. I could list Joe as Jane’s husband.

As you can see, NewTags are very powerful, but how to use them in your daily workflows? In the next section, I will share some of my workflows with you to see how I put this into practice.

My workflows

In this section will go over a few of my most useful NewTags: #url, #question, #project, #event, #overview, #notes, #diary, #contact, and #ck.

Let’s start with #contact, since I already discussed the ideas behind that above. Here are the properties I’ve assigned to this:

Most of these are fairly obvious, and I already explained how Relations:: works. But I do want to point out the Flags:: property. This is how I categorize my contacts. My flags include: work, businesses, friends, favorites, students, advisees, assistants, etc. This property allows multiple selection so multiple flags can be assigned to the same contact.

Some of my other examples are quite simple. The #url NewTag just has two properties: page refs:: and publication::. The page refs property allows me to link to any [[page reference]] in Logseq. This is useful if I’m doing research. For instance, if I am shopping for new [[headphones]], I can add a URL from the publication:: Wirecutter and link it to the page ref:: [[headphones]]. It will then show up in the backlinks on that page.

Another simple NewTag is #ck which stands for “check” and just adds a checkbox next to a node. This is great for when you don’t want to use the built in #task features of Logseq DB, but want to be able to check something off.

The trick here is using the UI position option to place the Checkbox at the “Beginning of the block.” Just adding #ck will now place a checkbox there. Here is how it looks:

The #overview NewTag is what I use for what some people in the PKMs community call “Maps of Content”: pages that bring together different kinds of data in your graph to give you an overview of that topic. There really aren’t any properties on this NewTag, but it does help me remember and find which overview pages I’ve created.

I use the #diary NewTag to add a sub-section to my journal pages. Logseq “journals” are really in-boxes for everything you enter into Logseq, but what if you want to enter a personal journal entry? I use #diary to do this. I also give it a few properties. I use the same page refs:: property I used with #url, but I also add a mood:: property. Like #ck this goes at the start of the block, and it just shows the emoji, not the property name.

And here is how it looks in practice:

The way I use #question highlights a very powerful feature of NewTags, which is that they can be used together. I will use the built in #task features of Logseq together with #question in order to assign a status and priority to each question. For instance

As you can see, this is just a regular “todo” item, with a “high” priority, but it is marked as a question, giving it a nice red question-mark icon at the beginning. Having its own NewTag allows me to create a NewTag table in which I can sort all my open questions by priority and status. This is very useful for research.

I will often use the #question tag while taking #notes on something. Like #question, I often combine the #notes NewTag with other NewTags, depending on what I am taking notes on. #media is used for video content, such as YouTube, or audio content like podcasts. The #publication NewTag is used for articles, books, or journalism. And the #event tag is used for meetings, lectures, or workshops. I won’t go into details, but each of these has their own set of properties, as appropriate for that kind of data.

Finally, I have the #project NewTag which is probably the most important NewTag I use.

Because projects group together #notes and #contacts and #tasks around a particular goal, I didn’t want to use the built-in #task status markers, so I created my own:

The “categories” for projects are a similar idea to how I used “flags” for my contacts - helping me group all my projects into a few larger groupings, such as “teaching,” “research,” and “writing.”

Conclusion

While NewTags are both powerful and fairly straight foward, figuring out how to use them in your own workflows does require some thought and experimentation. Compared with Logseq MD, it can be a bit harder to modify your setup after you have started to use it. Hopefully this post will give you a sense of what is possible. Do let me know if you have any questions.

Thank you for the great write up! What are the parent and tag type sections for?

1 Like

Cool thanks for that!

A video would be nice too, as it would allow showing more of the UI/UX. Though I appreciate it might get old fast, with so much changing so quickly.

Not important, but I’d advise against calling them “NewTags”. It’s not very intuitive, and can get quite confusing.

1 Like

Parent:: is a built in property from Logseq which is how “hierarchy” is now handled. In LogseqMD you could write [[pie/apple]] and [[computer/apple]]. You can still do this, but it will automatically be converted to [[apple]] parent:: pie or [[apple]] parent:: computer.

Tag type:: is something I created to help me keep track of my various tags. I use the following values: logseq tags, workflow tags, property tags, and topic tags. (I try to avoid using tags for topics, but there are a couple of exceptions.)

1 Like

I agree about NewTags, but all my efforts to suggest alternatives have so far fallen on deaf ears.

1 Like

Because everyone has an opinion and such debates can go on forever, I would prefer it if you started a separate thread for the issue of what this feature should be called. I’d like to focus here on helping people understand and use the feature - regardles of the name. Thanks.

1 Like

It’s really cool to see someone writing up how they’ll use the new system. I’m really looking forward to it.

I’ve tried to use properties but they can quickly take so much time to construct and enter that it’s proibitive and so I end up using tags ‘badly’ as in unintuitivly and in ways that are apt to cause me problems down the line.

I have a few questions about your setup. Not criticism just curious.

Using properties with multiple values rather than first and second contact number

I noticed you had a ‘Primary Phone Number’ and ‘Secondary Phone Number’. Did you design that before we had the option to have multiple values for a property or is there a reason you did it that way. (Maybe just personal preference)

Question and Idea

I’m so pleased to see someone using the ‘Question’ as a tag like this.
I use idea in a similar way. I haven’t nailed it down but my ideas tend to have a ‘state’. So currently I make that a property. The default is ‘unused’, then ‘in process’, then ‘implemented’. I’m toying with the idea of just using the integrated process set of properties but as ideas are never really ‘done’ I’m unsure. I’m also a fan of descriptive properties so ‘Implemented’ is something I’d find much more intuitive to engage with.

I do something similar when I have a #problem. Because any such note as a ‘Solution’ property which only accepts idea notes. Hence when I’m writing I’m tagging a note is a concern, a problem, an idea (which could be used as the ‘solution’ property)

Anyway enough of my rambling. It’s nice as I say to chat about it. Any feedback wild be welcome. I certainly haven’t settled on exactly how to implement it all yet.

1 Like

I noticed you had a ‘Primary Phone Number’ and ‘Secondary Phone Number’. Did you design that before we had the option to have multiple values for a property or is there a reason you did it that way. (Maybe just personal preference)

Better data structure.

Phone:: 845-555-1212, 956-333-4545

vs.

Primary Phone:: 845-555-1212
Second Phone:: 956-333-4545

This way I know which phone to use first! They also show up more clearly on the tag table.

I use idea in a similar way

I have not yet decided how best to handle ideas. I generate so many that they tend to get lost. I think I need some way to distinguish ideas that are pure flights of fancy from ideas that I am likely to followup on.

1 Like

your breakdown and article are invaluable. you and danzu’s videos and updates, and also ed, you are the only ones fleshing out the new exciting features of db alpha. and they are exciting, literally, because so much scalability and flxibiliity are being built in, along with some new extra structure to allow it (sqlite db vs md old logseq). now larger use cases dont have to worry about maxing out logseqs ability to handle whatever may come, as far as graph size, performance on normal computers, etc. thank you. and newtags seems like a great name to me, to constantly remind people we’re talking about bd and the new possibilities it brings, not md tags.

2 Likes

Thanks @Luhmann, for this detailed write about these new tag features.
Exactly what was missing the whole time in Logseq.

1 Like

let’s say there’s a company tag, and that has some phone numbers. and lets say you have 50 people at a company in 1 location, 1 phone number. and then the # changes. is there a way to mass-edit that one property to a different value? or would it be better to have a relation, so that all 50 people point to a single company record, so that when the single phone on that company record is changed, the change is reflected on all 50 people, since the phone number field is only referenced, and not static data? you know what im saying? i dont know how to use your tricks and tips to accomplish that.

Yes, I think this would be the best way to handle this.

I agree with @Luhmann.

I try not to duplicate relationships unnecessarily. So you have to ask yourself why do all these people have the same number. If they have that number because they work at that company then the company is the central point of reference. So as you say, rather than change every number individually it matters sense to connect the person to the company.

With New tags I’d recommend setting up a ‘#company’ tag with a property ‘contactnumber’ or similar.
Then make a ‘#person’ NewTag with a ‘company’ property and full in that property with the relevant company.

The only thing we’re missing which I don’t think is possible it to be able to access the property of another node. E.g. have the ‘person’:contact=‘company’:contact.
That’s something I’m looking into at the moment.

2 Likes

This seems like an interesting and innovative idea.

I’m a bit concerned about the impact it will have on my normal tag usage. For instance,

  • will I have to rewrite all of my old #tag into [[tag]] before importing into LSDB, so my old tags don’t get interpreted as NewTags?
  • I use a lot of #tags in my writing, and if all of those will become [[tag]] then it’s 4 keystrokes instead of 1 and significant visual noise. I wonder if it would be possible for users to customize the syntax to give normal tags less syntactic overhead, eg by using {{NewTag}} and #oldtag?

Thanks for your thoughts.

I understand that the conversion will be automatic actually otherwise that would be really quite laborious.

Yes I agree about one single hashtag being easier but I don’t think you’re right about needing 4 keystrokes. Currently and on the new version you only have to do one half of the brackets and the system inserts the other half. So typing ‘[’ will result in the computer entering the other side ‘]’. It also doubles up so typing ‘[[’ leaves you with ‘[]’ but the cursor is still in the middle rather than at the end so you can then just start typing the tage/page reference you want.
Admittedly typing # is quicker but just double tapping [[ isn’t that much work. Also after you’ve found your tag and selected it the cursor then jumps to the end so you can carry on typing.

I think this functionality has basically always been there. It also works for other brackets as well as some symbols which add formatting like * for italics and bold.

Import offers you a number of choices. I recommend testing out import over at test.logseq.com to see how different options affect your graph. Import won’t affect the original files so you can test different scenarios.

I really love the ability to make child tags that inherit the features of the parent, but have additional properties.

I just created “#next steps” which is a child of “#tasks” but has the additional property “parent project::” that links to the “#project” node.

This is specifically for tasks that are sub-tasks of a project. Then I can easily query those tasks on the page for that project, using just a simple query for the tag #next steps, followed by a filter for the specific project.

This allows me to add a task for a project anywhere in my graph, but still see it all in one place when looking at the project.

It is so simple, but so powerful…

Compare this to the complex workflow I had to create in order to accomplish the same thing in logseq MD: My Logseq Workflow

UPDATE: Because of how queries work, it seems it is best to apply two tags: #next steps + #tasks and to keep #next steps as a child of root. At least for now…

1 Like