Confusion due to different behavior of how tags are extended

Questions & Help
1

Before using Logseq DB I did some research how to structure data. The website schema.org provides a great example for structured data. When applying parts of this schema I noticed different behavior of Logseq DB. Unfortunately there isn’t information if one of these behaviors is incorrect and might lead to conflicts in the future. This is currently holding me back of further exploring Logseq DB. Therefore I’m looking forward to your opinion of the following. What do you think, is one of these scenarios incorrect?

The below the structure/hierarchy (partially from schema.org) is the goal:

Root tag
Thing
– Intangible (extends Thing)
— PostalAddress (extends Thing/Intangible)
– Place (extends Thing)
— LocalBusiness (extends Thing/Place and Thing/Intangible/PostalAddress)
– Person (extends Thing and Thing/Intangible/PostalAddress)

1st scenario - The tag #Person won’t extend Thing and Thing/Intangible/PostalAddress

  • Start with a new graph
  • Create tag #Thing
  • Create tag #Intangible
  • Set extends field (parent tag) of #Intangible to ‘Thing’
  • Create tag #PostalAddress
  • Set extends field (parent tag) of #PostalAddress to ‘Thing/Intangible’
  • Create tag #Place
  • Set extends field (parent tag) of #Place to ‘Thing’
  • Create tag #LocalBusiness
  • Set extends field (parent tag) of #LocalBusiness to ‘Thing/Place’ and ‘Intangible/PostalAddress’
  • Create tag #Person
  • Set extends field (parent tag) of #Person to ‘Thing’ and ‘Intangible/PostalAddress’

Notice that the last step is not possible. The system will remove the previous extends field when you select the second one.

2nd scenario - The tag #Person accepts the extend Thing and Thing/Intangible/PostalAddress

  • Start with a new graph
  • Create tag #Thing
  • Create tag #Intangible
  • Create tag #PostalAddress
  • Set extends field (parent tag) of #PostalAddress to ‘Intangible’
  • Create tag #Place
  • Set extends field (parent tag) of #Place to ‘Thing’
  • Create tag #LocalBusiness
  • Set extends field (parent tag) of #LocalBusiness to ‘Thing/Place’ and ‘Intangible/PostalAddress’
  • Create tag #Person
  • Set extends field (parent tag) of #Person to ‘Thing’ and ‘Intangible/PostalAddress’
  • Set extends field (parent tag) of #Intangible to ‘Thing’

The hierarchy from the tag #Thing is now as the screenshot below. Notice that the tags #LocalBusiness and #Person are mentioned twice in the hierarchy (the desired result).

image
image334×403 13.2 KB

2

Okay so, there are 2 different things at play here

  1. This is the most important point: you shouldnt create the structure you have in mind in such a manner in Logseq. You should understand clearly what “Extending” a tag is: this means that the Child tag is of the same “type” or “class” as the Parent tag. For example, lets say I have a tag #Book. I could then create two other tags, #LiteratureBook and #PhilosophyBook, and Extend both of these tags with the #Book tag (this means I would go to the LiteratureBook tag and set its Extends property to Book, and the same for PhilosophyBook). This makes sense because all Literature books are Books, and the same can be said for all Philosophy books. Lets now look at another example, lets say I have a #Person tag. What I could then create is maybe a #Friend tag, and Extend it with #Person, because all my Friends are “Persons” (people). What you shouldnt do, and its kind of similar to what you are doing, is create a new tag called #Job and Extend it with #Person. Again, remember that in Logseq, this is not what Extending a tag is for. While (most) people have a job, you do not represent this in Logseq by extending #Job with #Person.
    So, what do you do? You use Properties, specifically Tag properties. Tag properties are properties that are inherited by all blocks with that tag. For example, all blocks tagged with #Task have 4 properties: Status, Priority, Deadline, and Scheduled. This is because the Task tag has these 4 properties as its Tag properties. But you can do the same with your own tags, you just need to hover above the title of the tag and the “Add a new tag property” button will show up.
    How does this relate to your case? Well, think about the structure you have. Intangible extending Thing makes sense, because all Intangibles are Things. The same can be said for Place extending Thing. However, should LocalBusiness extend both Place AND PostalAddress? No, because a Local business “is not” a postal address. A local business HAS a postal address. The same thing happens with Person, a person has a particular postal address, but they are not a postal adress themselves. What you should do instead is add a Tag property for both Local business and Person, and you can call this property “Postal address” (personally, I would assign it the Number type). This way, all Persons and all Local businesses will have a Postal adress field for you to fill

  2. As for the other point, the difference between the 2 scenarios, is that in actuality I think there shouldnt be a difference between them and you may have encountered a bug lol. The reason why in the first scenario you cant extend Person with both Thing and PostalAdress is because PostalAdress extends Intangible which extends Thing, so its kind of redundant. Going back to the previous example with Books, lets say now I want to create a new tag only for #ScienceFictionBook s, and I would extend it with #LiteratureBook. Then, it would serve no purpose to try and extend it with #Book, because its already a Book since all Literature books are Books

1 Like
3

Thanks for the extensive answer. Following your example of book. Let’s say you would want to give it a rating following the Schema.org rating (six fields). You would apply all six fields as properties? That sounds a bit inconvenient when these rating fields are used in other tag in example podcasts, movies, interviews, etc.

I thought the whole idea behind extending tags is that you can get all properties from the extended tag added to multiple tags to keep consistency and have a list off all ratings given (because it is a tag rather then a property).

4

What do you mean by it being inconvenient? Maybe we are misunderstanding one another.

There are 2 ways you could add a Rating in this manner.

1 ) Extend #Book with #Rating, which is what you were planning to do the first time. Lets say the Book tag has 3 tag properties: Author (Node property), Year of publishing (Number property) and Topic (either Select or Node property), and lets have an example of a book

  • The Wealth of Nations #Book
    • Author: Adam Smith
    • Year of publishing: 1776
    • Topic: Economics

Now, lets say the tag Rating has 2 tag properties: Value of rating (Number property), and Rating explanation (Text property). Now, I extend Book with Rating, and so the book will now look like this:

  • The Wealth of Nations #Book (extends #Rating)
    • Author: Adam Smith
    • Year of publishing: 1776
    • Topic: Economics
    • Value of rating: 5
    • Rating explanation: I believe Adam Smith is a great writer and his book taught me many things

So each book will now have these 2 fields to fill (since they are inherited from the Rating tag). Considering how we have set up the tags, a more appropiate name for the Rating tag in this case would be “HasRating”, and then you can extend all the things that have a rating with this tag, like Movies, Shows, Podcasts, etc.

OR

2 ) You could have actual distinct Rating objects. This would be kind of a pain, but it has the added benefit of being able to add multiple ratings to one thing. So building on our previous example, lets say now I really do have a Rating tag where I will keep all my Rating objects which will be distinct from the things Im rating, so I wouldnt extend Book with Rating for example. I would only need to add a new tag property to Rating, like “Thing Im rating” (Node property). So this is what some journal entries could look like

–
May 19, 2026

  • The Wealth of Nations #Book

    • Author: Adam Smith
    • Year of publishing: 1776
    • Topic: Economics

  • Today I read wealth of nations since it was assigned reading for class. I liked it a lot! #Rating

    • Thing Im rating: The Wealth of Nations
    • Value of rating: 5
    • Rating explanation: I believe Adam Smith is a great writer and his book taught me many things

–

So whats the benefit of this approach? As I mentioned earlier, this allows you to have multiple Ratings for the same object. Lets say you reread The Wealth of Nations 4 years later:

–
May 20, 2030

  • I reread the wealth of nations, and it sucks #Rating
    • Thing Im rating: The Wealth of Nations
    • Value of rating: 2
    • Rating explanation: He got many things wrong and there are better books on Economics

–

PS: I forgot to mention, you could also add a “Maximum rating” property to the Rating tag, but this would force you to fill this field every time you rate something, even if you always use the same maximum (in this example I was considering 5 to be the maximum)

5

Your described first scenario sounds exactly how I’m using it (when not adopting the schema.org structure). Let’s say there’s a person with two properties set (birthday and phone).

  • John Deere #Person
    • birthday: 6-10-2026
    • phone: +1 234 567 890

A Person does also have a PostalAddress (with three properties). Now there are two scenarios:

    1. Set two tags, #Person and #PostalAddress
      John Deere #Person #PostalAddress
    • birthday: 6-10-2026
    • phone: +1 234 567 890
    • street: Napoleonstreet 100
    • city: Berlin
    • postalcode: 54321 XYZ
    1. Set the tag #Person which extends #PostalAddress
      John Deere #Person
    • birthday: 6-10-2026
    • phone: +1 234 567 890
    • street: Napoleonstreet 100
    • city: Berlin
    • postalcode: 54321 XYZ

Both work fine. Now let’s dive into the data structure of the tags (from schema.org) and where they extend each other. The below structure only reflects one parent/extend.

  • Thing
    • CreativeWork
      • Book
    • Intangible
      • StructuredValue
        • PostalAddress
      • Rating
    • Person
    • Place
      • LocalBusiness

In order to rate the Book the tag Book must also be extended with the Rating tag. Now the structure in Logseq looks like this:

  • Thing
    • CreativeWork
      • Book
    • Intangible
      • StructuredValue
        • PostalAddress
      • Rating
        • Book
    • Person
    • Place
      • LocalBusiness

Now let’s extend LocalBusiness with a PostalAddress. The structure becomes:

  • Thing
    • CreativeWork
      • Book
    • Intangible
      • StructuredValue
        • PostalAddress
          • LocalBusiness
      • Rating
        • Book
    • Person
    • Place
      • LocalBusiness

Now let’s extend Person with a PostalAddress. The structure becomes the following (notice that Person moves from Thing to Thing/Intangible/StructuredValue/PostalAddress while with the previous example the LocalBusiness tag isn’t moved):

  • Thing
    • CreativeWork
      • Book
    • Intangible
      • StructuredValue
        • PostalAddress
          • LocalBusiness
          • Person
      • Rating
        • Book
    • Place
      • LocalBusiness

So what is the best approach in this? Should the structure from schema.org be abandoned and if so what is the ‘best’ way of setting up this structure?

6

Just wanna add, I too spent some time scratching my head around tags.