Same name for Tag and Page in the database version?

Questions & Help
1

I know that in the new Logseq database version there is a conflict if you give the same name to Pages and Tags. My question is: What is the proper way to handle these situations?

Because there are many times where you want a Tag and a Page with the same name. For example, you might want to have a Page named Japan (where you keep all the information about that country), but you also need to have a Tag named #Japan to tag items that are made or have a relation with that country. How can this be handled properly in the database version?

My thought is to add some extra characters to the Page version of the name — so that Logseq sees it like a completely different name and have no conflict — and use the literal name for the Tag. For example I am thinking to add at the end of the Pages names something like (Page) or (📃). So the Page will have a name like: Japan (Page) or Japan (📃) and the Tag name will be just #Japan. And finally, tag the Page with the Tag so that when Querying using the Tag, the Page appears in the results.

Is there a better way to handle this?

2

The need for same-named tags and pages is real, but not in cases like Japan.

  • More specifically, all proper names:
    • should be capitalized
      • At least in those languages that make such a distinction between words clear.
    • deserve to be pages
      • Things are given names exactly because they are important.
    • should not be tags
  • Therefore:
    • japan is wrong
    • #Japan is wrong
    • Japan is right

For “items that are made or have a relation with” Japan, the proper thing to do is to use a reference inside a phrase that describes exactly that relation.

  • e.g. This thing is made in [[Japan]].

In the database version, a tag is supposed to apply a set of properties. Japan is not a tag, but is a valid candidate for being tagged itself as a #country, acquiring properties like flag::, capital:: etc.

1 Like
3

I can see your logic on the Japan example and I agree. I haven’t thought of it this way. It’s so confusing.

But if Tags are not meant to tag anymore, then how do we mark blocks and pages with certain terms? What do we use in place of the Tags?

In the old Logseq I used to write something and then tag it with whatever tags I thought it was related with. Should I make everything a Page and use pages in place of the Tags? I am very confused.

4
  • In “the old Logseq” all tags were also pages.
  • Inline references remain the best tool.
  • If you really need to add multiple one-word marks in a fast fashion, you can create once a node-property marks:: and write them inside.
    • This will even suggest in auto-complete the values that are already used for marking.
5

Thank you @mentaloid for your help.

This reminds me of how it could be done in the old Logseq with properties. Where you could add a property named tags:: and add multiple tags:tags:: Tag1, Tag2, Tag3 .

I am experimenting with a similar concept using a property named keywords but in Logseq db you have to specify a Type for the values that the property accepts. And here is where I struggle. What Type the values of the property keywords should be since I can’t use Tags?

6
  • If they are mere keywords, they should be of type Text.
  • If they are pages, they should be of type Node.
7

I still wonder why not call them classes… :thinking:

1 Like
8

Yeah. Since the new tags don’t behave as people expect Tags to behave — and not only in the sense of the old Logseq MD, but everywhere else. Like, how people use Tags in other apps or in social media — maybe a change of the name should be considered. It’s misleading and confusing to call something Tags that does not behave like the Tags the users expect.

For now, I am leaning towards to make Pages named as I would name single tags and use Node Type: Page inside a property named something like keywords in the way that I used the old tags. And then use the new tags only to add properties to other Nodes and Pages.

I still need to experiment a lot before using the new Logseq DB full time.

9

Since the functionality for the Tags have changed drastically from how people use Tags, how about calling them #PLables with P standing for Property. They are not Tags anymore, they are a #PropertyLabel.

So the users, when thinking about #PLables and what are they for, they could easily remember that a #PLabel is a Label that provides Properties to the item it is attached to. Avoiding the trap to associate it in their mind with Tags.

Classes might be more accurate term, but it makes more sense for someone who is a programmer and know what a Class is in programing terms.

I also thought about calling them #PTags (as in #PropertyTag) but having the word Tag in it, it would still trip people to use them as the old Tags.

10

Sad to read that one of my favorite features of logseq (pages=tags) is dropped -_-