Would a rich commitment to hierarchies and classification be an anathema to Logseq culture?

General
20

Hi @boisjere and @alex0,

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:
  • 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 the child, and in the stuffedAnimals 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

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 and related
      • 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

  • 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 only animals:F. catus, from which Logseq can infer that we are dealing with a type of cat.

  • 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