Extended Tags and Inherited Properties

This entry is intended to provide a further explanation with examples of how extended tags and inherited properties work in the DB version.

Each tag can have its own unique properties that you define. Any object to which you assign that tag will have those properties. If you select another tag in the “Extends Tag” property, then the properties that are defined for the parent tag you selected are also associated with the tag extending it. Extending a tag allows the child tag to inherit the properties of the parent tag. A tag can extend more than one parent tag, as well. That child tag will present tag properties of all of its parent tags, but the parent tags have no direct relation to each other. If two separate tags are extended by the same child tag, the parent tag will each only be associated to its own properties. To provide a concrete illustration, below are screenshots of the properties and values for three example tags illustrating possible information from the cartoon, Coyote vs Roadrunner:

  • #CaptureTool: (information is about things Wile E. Coyote might want to use to catch the Roadrunner)

  • #Failures: (information about outcomes when Coyote didn’t catch Roadrunner)

  • #CunningPlan: (extends both of the other two tags since the Coyote believes that no plan is truly cunning if it doesn’t have a good tool but he also wants to keep track of his failures so he can make better plans)

CaptureTool

The basic CaptureTool just has two properties - Type of Approach property (how to use the tool) and a Manufacturer property (who makes it). (CaptureTool extends “Root Tag”, which is just the default parent tag for all tags.) Note that on the table view, even though the table is for the CaptureTool tag, it also displays rows for its child tag CunningPlan; CunningPlan is included with its parent tags in a view; for purposes of grouping, the child is included within the parent.

#Failures

Like the CaptureTool tag, the Failures tag has just two properties: the Quarry property (who was being pursued) as well as the Mode of Defeat property (how did it go wrong). Like with CaptureTool, the CunningPlan tag is displayed in the list of the Failures tagged items.

#CunningPlan

CunningPlan has its own specific properties for Fastener and User. You can see that it extends CaptureTool and Failures, though, so the properties of those tags are also visible in the table and list view for CunningPlan. Note that the parent tags aren’t included with the child tags in a view.

Compare the properties visible in the CunningPlan list view for “wear harness…” below with the CaptureTool table view of “wear harness…” above. When “wear harness…” is seen as part of the CaptureTool table, it only shows the values for the CaptureTool properties - and only those CaptureTool properties - in the table. However, a list view under the parent tags will show all property values for “wear harness…”.

CunningPlan - all properties in a table view

#CunningPlan List View

A block tagged #CunningPlan shows the properties for CunningPlan, the properties for its parent CaptureTool, and the properties for its parent Failures.

Also compare the list view below for the items under CaptureTool that do not also appear under CunningPlan. CaptureTool items don’t have the CunningPlan properties, because property inheritance only flows from parent to child and not the other direction.

Lastly, if you were to change the parents for CunningPlan so that only CaptureTool was its parent (note the Extends on the right side of the screenshot), it would no longer inherit the properties for Failures:

(The information I’d already entered for the Failures properties isn’t deleted just by removing Failures as a parent tag and will show up in the list view. Data isn’t deleted by removing a parent tag; it just becomes no longer visible in certain views.)

Root Tag Properties

The “Root Tag” is the default parent of any tag that is created. If you create a tag property for the Root Tag, all other tags will inherit that property, too. When you tag a block in Logseq, those Root Tag properties will be visible under the block. If you add a Root Tag property later, the new property will appear under all previously tagged blocks, as well.

As you can see above, the “wear harness…” item has the Root Tag properties for the block even though that item was created before the properties were added to the Root Tag.

When you go to any tag’s details view, the properties it inherits from the Root Tag will show directly under the tag name (including under the Root Tag name itself), and then the properties specific to that tag will appear slightly indented in the “P Tag Properties” section of the details.

In the screenshot above, you can see that I have given the tagdate property for the Root Tag a specific value, but that specific value is just for the Root Tag itself. In the screenshot below, you can see how it appears in the table view for Root Tag but not for other tags.