I’ve started to draft a feature request on:“Knowledge Management for tags / Hierarchical tags”. Please let me know what you think:
Why do we need Knowledge Management for Tags?
- Tagging leads to a large number of unrelated tags, easily many thousands
- Browsing these tags through a list, graph, or tag cloud, is not very efficient
- Many efficient search strategies exist elsewhere:
- faceted search on Amazon
- browsable hierarchies, like the Dewey system or taxonomies.
- mixed hierarchies. Searching for “Architecture” on [OpenLibrary] (Architecture | Open Library) lets us then narrow down the search by Subjects, Places, People, Times,…
- All of these search strategies require knowledge of the relationships between tags
- Logseq’s hierarchies of the form
[[parent/child/teddy]]
are not enough- Each child can only have one parent (
teddy
can be both in thechild
, and in thestuffedAnimals
category, but currently this can’t be recorded) - The classification is specified on the pages themselves and can’t be added on later
- If I tag 100 pages with
teddy
and later want to add the tag to a hierarchy, I need to edit every single page. Instead, it should be possible to tag pages, and then later classify tags centrally, making all of the original pages findable under the proper hierarchies
- If I tag 100 pages with
- Each child can only have one parent (
What needs to be done?
- Logseq needs a way to specify relationships between tags:
- TagA is a broader/narrower version of TagB
- TagA is related to TagB
- These relationships are captured centrally, such that tags can be managed without editing each tagged page individually
- We need a user interface to hierarchically browse Logseq pages (not part of this feature request)
Example use case
- Unsinkable Sam example goes here
Example implementation
-
This example uses Markdown to represent a subset of the Simple Knowledge Organization System, which is widely used, e.g. by libraries.
- Tags are connected using the relations
broader
,narrower
,broaderTransitive
,narrowerTransitive
andrelated
-
broader
,narrower
- specify that one tag represents a broader/narrower concept than another
-
broaderTransitive
,narrowerTransitive
- specify that one tag represents a broader/narrower concept than another and all its children/parents
- e.g. A Cat is a narrower concept of a mammal, which automatically makes it a narrower concept of Animal
-
related
- two tags are related, e.g. Apples and ApplePie
-
- Tags are connected using the relations
-
I am not tied to any specific syntax, this is just an example how it could be done in Markdown itself.
- Alternatively, Logseq could directly parse SKOS RDF/Turtle description files.
- SKOS is a minimal example, other knowledge management systems exist and in principle Logseq could record arbitrary relations between tags.
-
The following relationship is a (small) section of the animal taxonomy.
Sub-items of the list are more narrower terms for their parent items. The lists can me arbitrarily nested. For example. Chordata and Mammalia are both narrower terms for Animalia. For a non-transitive relationship, Chordata would be a narrower description for Animalia, but Mammalia would not.- The animal taxonomy has the namespace
animals
to distinguish it from other hierarchies that can exist in parallel. One item can be in multiple hierarchies at the same time -
semanticRelation::narrowerTransitive concept::animals - Animalia - Chordata - Mammalia - Carnivora - Feliformia - Felidae - Felinae - Felis - F. catus - F. silvestris ```
- This information is stored in a central Markdown file
- If a user tags an item with
animals:F. catus
, the item will automatically appear in a search for Animalia - The user does not need to tag with the entire hierarchy
animals:Animalia/Chordata/Mammalia/Carnivora/Feliformia/Felidae/Felinae/…, as this would duplicate the hierarchy on every item. The tag is onlyanimals:F. catus
, from which Logseq can infer that we are dealing with a type of cat.
- The animal taxonomy has the namespace
-
Here is an example of a user-defined hierarchy that has non-unique names. It is not a taxonomy, but it is still useful to be able to capture such relationships, so probably this case shouldn’t be disallowed. If we require the user to provide minimal context, e.g. nutrition:Beef/Recipes instead of just nutrition:recipes, we can make tags unique. This will make any blocks/pages so tagged so visible under the Products, Meats, and Beef categories.
``` markdown semanticRelation::narrowerTransitive concept::nutrition - Products - Meats - Beef - Recipes - Nutrition - Pork - Recipes - Nutrition ```
-
This is an example of a “related” relationship. All of the tags [frying, deepFrying, airFrying, grilling] are marked as related.
- If a user tags an item with the tag frying, a search for related items will bring up the other 3
semanticRelation::related concept::cooking frying deepFrying airFrying grilling
- Related tags can also live in different namespaces
semanticRelation::related cooking:frying nutrition:fat
- If a user tags an item with the tag frying, a search for related items will bring up the other 3