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

[gax]

Thank you for this excellent writeup.

@boisjere

I think an actual faceted search is probably best implemented in a plugin. If the data model is there, then various kinds of facet search plugins can leverage it. It’s essentially a query GUI, isn’t it?

I am not familiar with Logseq’s internals, but I think a plugin would be the way to start initially and let different ideas compete. Later on it might become integrated into the core.

@boisjere

I’m not sure that the idea of a single classification hierarchy like the Dewey Decimal system bothers me, because I don’t think classification in that sense is even possible in this type of environment.

I personally very much dislike these ancient classification systems, because I wasted a lot of my life trying to organize things in such a way. I see people on the Zotero and Calibre forums ask all of the time how they can maintain their library as a folder structure sorted by author/title etc, so these ideas are alive and still doing a lot of harm.

My worry is that, because everyone is familiar with library classifications, people might think that this is the state of the art and oppose far superior approaches.
I’ve received massive pushback at work trying to implement something that would have been trivial in a database, but management wanted and got a hierarchical folder structure that was virtually unsearchable and a complete failure.
I suspect that any proposal will get some pushback as well, saying that we can solve the issue with tags or with the rudimentary hierarchical page structure that already exists. This is why we have to explain very clearly how these old systems were made to deal with physical realities of index cards (à la Luhmann’s Zettelkasten) and items stored on shelves.

@boisjere

An index isn’t polyhierarchical necessarily - it uses “see” and “see also” references to related concepts (skos:related) - but again that’s kind of vestigial from the fact that indexes have historically been created on paper. (One might say that “Unlinked References” is an evolution of these “related” index entries).

That’s why I like the SKOS concepts, they allow indices, (poly) hierarchies, and they can also be completely ignored and fall back on what we have now.

@boisjere

Feature Request 2: Hierarchy Page

I don’t know how hierarchies/namespaces are currently implemented under the hood. But my initial request, listed as Feature Request 2, is just the first bullet, more or less.
…
I see this feature as a quick hit for the development team. It may not significantly derail their roadmap to squeeze it in. It would also be a clearly visible differentiator from Roam, if that’s important. For that reason, I’d pop it into the Feature Request forum as its own thing.

sounds good

@boisjere

Feature Request 1: I Would Split it in Two

It seems to me that Feature Request can be unbundled a bit, split into two or three features. I’ll do it as two features.

FR 1.A: Polyhierarchies

Polyhierarchy is a distinctly different feature request. It could be implemented without there being an autocompiled list of all hierarchies, with a system link to it in the left sidebar (i.e. without Feature Request 2).

Now my ignorance is going to show here. Wouldn’t that mean that the place of a page in a hierarchy would have to be defined in a page property or page tag, as opposed to slashes in the title? I like deep trees and so the slashes in the title is a pain for me, so I’d be happy to do it differently.

I dislike specifying the full hierarchy for every item. That would also require memorizing the taxonomy or relying on autocomplete.
My thought was to have a separate taxonomy file that specifies the relationships between tags. In the case of taxonomies, these are very simple nested lists. In the case of general SKOS concepts it is more complex and would require writing down the relations, but this could also be mapped to Markdown.

The process would look like this:

• specify relationships between tags through user-defined taxonomies.
  • for example, we have a document that specifies the taxonomy of animals. As this is a simple list that narrows transitively it can be represented by a nested Markdown lists.
  • Here is a small part of the classification of animals:
    • |Kingdom:|Animalia|
      • |Phylum:|Chordata|
        • | Class:|Mammalia|
          • |Order:|Carnivora|
            • |Suborder:|Feliformia|
              • |Family:|Felidae|
                • |Subfamily:|Felinae|
                  • |Genus:|Felis|
                    • |Species:|F. catus|
• as you suggested, this list could be imported
• adding a tag automatically places the item in the right spot of the hierarchy if the tag is unique in the taxonomy
  • A block on the common house cat will be tagged animals:F.catus, which will make it appear in the hierarchy in the right place, it will be returned in a search Felidae etc.
• if the tag appears in multiple places in the taxonomy, a sufficiently long path needs to be specified to make it unique
  • I don’t think this happens much in good taxonomies, but it is no problem, if there where two species with the same name but in different phyla, one just has to specify enough of the path to make it unique.
• if the tag appears in multiple taxonomies, we need to specify the namespace (probably this should be done for any taxonomy for future extensibility)
  • For example, the tag Felidae could point to the animal taxonomy, the novel, or the film with the same name. If a user has imported both a taxonomy of animals and of movies animals:Felidae and movies:Felidae make clear which one is meant (and an item might have both tags and appear in both hierarchies)

@boisjere

I see references that indicate to me some other ways of defining namespaces in other places in this forums:

• Collapse namespace prefixes - #9 by Alex_QWxleA
• Collapse namespace prefixes - #11 by Aryan
• Collapse namespace prefixes - #14 by cannibalox

Anyhow, all that is to say that Polyhierarchies (having a page appear in multiple namespaces) can be implemented without having a sidebar link to an overview page, and vice versa.

I think it’s a different kind of feature request from Feature Reques 2, because it does touch how namespaces work, potentially.

I still think it’s a smaller feature request than implementing SKOS (provided Logseq isn’t architecturally similar to SKOS already).

FR 1.B: Vocabulary Control

Having a nested hierarchy of terms (broader, narrower, related) is different from having branching hierarchies of namespaces. In Ranganathan’s terms, it’s classification on the “conceptual plane” as opposed to the “physical plane” (I’ll treat digital notes as “things”, and so they’re analogous in some ways to objects - on the physical plane).

How are conceptual hierarchies different from hierarchies of things like notes? You can construct namespaces (for locating things like notes) any way you like. It’s essentially manual outlining, on a macro level above the page level. There are no conceptual limitations on what you put where.

I am torn about this. On the one hand side, conceptual hierarchies, indices, related items etc. are different. On the other hand, they can all be represented by the same relations like SKOS does.
If Logseq had a way to specify the following relationships for tags:

• taxonomies (as in the example for cats above, not strictly needed, but it simplifies things)
• transitive and intransitive broader and narrower relationships
• relatedness
• (do we need anything else?)

then all of the concepts, from full imported taxonomies, user-defined taxonomies, indices could be represented using the same mechanism.
For this reason, I think from a software design point of view, they should all be integrated.

@boisjere

You could import a taxonomy of animals, or a medical taxonomy, industries or minerals… whichever of those is important to you. There are lots of these official taxonomies, as you know. But this would give you a pre-structured set of properly-organized tags for organizing knowledge in the same way that your larger discourse community organizes it.

This is an excellent idea!

If the taxonomies were specified as simple .md files, it would be very easy to edit and share them.
Importing existing taxonomies would indeed be a killer feature for Logseq. What I especially like about this that it wouldn’t force the user to put any item into the taxonomy, like in a folder structure.
Let’s say I learn about medicine, if I start with a folder structure it will be mostly empty and it will be difficult to locate items. Also, as a beginner, I will probably not completely understand how things are classified in the field. On the other hand, if I can import the taxonomy, I can “tag” my items with one or multiple locations, or leave them as-is.
An item can also be part of multiple taxonomies, so if I work on the healing force of crystals, I can place an article on amethyst into both the medical and the mineralogical taxonomy.

@boisjere

It sound like you - like me - want to create your own bottom-up taxonomy of tags. I want that, with a thesaurus to keep track of (groom) term trees, to keep them clean.

I see Vocabulary Control as distinct from Polyhierarchy. Vocabulary control is very important to me as I envisage long-term use of these tools. I have no illusions that every note can or should fall within the scope of any one taxonomy. Taxonomies are MOC-style notes like any others, that structure segments of the graph - but they’d need to enforce the SKOS nesting relationships defined within them.

Thanks for bringing up vocabulary grooming, the lack of which has become a major issue in Zotero. Items have user-defined and automatic tags (e.g. from a library import). I chose to use and keep the automatic tags (they are meaningful tags after all), which means that now I have thousands of items with tens of thousands of tags, many of which are duplicates, often just different capitalizations. If I deleted automatic tags, I would lose the classification of many of my items. Sadly, Zotero offers zero help in this, even if I rename items by hand, on the next import I might get unwanted tags back. Logseq absolutely needs a way to deal with this, as it will e.g. inherit the badly tagged Zotero databases.

@boisjere

Idea: Logseq MOCs / Outliner MOCs / OMOCs

What I’m seeing here is the emergence of Logseq MOCs - or Outline MOCs (OMOCs) a distinct form of MOC native to outliners, with enforced indenting to preserve hierarchical relationships that span assemblies of notes (for manual page hierarchies) or ideas (for SKOS-light taxonomy-type conceptual relations) - but you can add notes to make them more informative than just TOC-like header links.

Question: Are Conceptual OMOCs Queries?

I think for the bottom-up conceptual OMOC, what I think you’re suggesting is the creation of a taxonomic index to notes. So you have a page with a taxonomy (you might zoom into specific blocks of it). There you find links to any notes you’ve decided to situate in that taxonomy, by tagging them with terms that fall within that taxonomy’s scope.

Navigating the taxonomy (the page defining the broader, narrower and related terms), would show links to the notes that have been gathered around those terms. It would pull notes into a hierarchy without using explicit namespaces. It’s a separation of the tree-making and leaf-placement concerns.

The concern of a taxonomy is hierarchy-construction. You make the tree as its own term-based thing, independent from notes, but it defines tags. You use those tags throughout your database. Then when you use the taxonomy page to explore the notes aggregated by that hierarchy, any notes you’ve tagged using those terms appear in place.

To express this second point a different way, notes flag themselves for inclusion within a hierarchy by wearing a tag belonging to it. (This is very Tinderboxy)

I see this taxonomic/conceptual plane organization as distinct from polyhierarchy. Polyhierarchy can possibly work with branching hierarchies of “things” only, not nested conceptual ones. So I think polyhierarchy and SKOS are different asks.

they seem different from the point of the user, but under the hood they are all relations between tags. If we specify that TagA is a broader version of TagAA, we get a hierarchy (taxonomy), if we specify that TagA is a transitive narrower version of TagX and TagY we get a polyhierarchy that automatically includes all of the children of TagA (such as TagAA and TagAAA), and if we specify the intransitive narrowing we get only TagA as narrower versions of TagX. If we specify things as related, we get a “see-also” entry. If we want an index, we can rely on the ordered collections. So from a software engineering point of view, with just 5 relations, we can create almost any type of hierarchy.

@boisjere

Splitting the First 2 Feature Requests into 3 Requests

I agree with you that if you are going to do any of this, it can theoretically be done using SKOS.

If I use namespaces to create branching hierarchies of notes, with no semantics that other people would care about, that can just be my own idiosyncratic instantiation of what, under the hood, is a concept hierarchy.

However, in terms of incremental steps towards developing these features, it’s possible that Feature Request 2, bullet 1, is quick and easy.

Polyhierarchy using the same namespace logic as the team currently uses might be a bit more work, but may not strain the existing architecture too much.

To allow the construction of SKOS-based conceptual taxonomies, and automatically aggregating links to notes tagged for inclusion in taxonomical indexes… the relative difficulty of doing this depends on how hospitable (or how “close”) the Logseq architecture is to SKOS already.

Perhaps its a North Star, and the team should try to make new developments future-compatible with SKOS, but it may not be something they can deliver in one incremental step yet. It may be more of a Saga than an Epic.

Feature Request 3: Tree Search

Maybe this isn’t a feature request to the development team at all, but a user-community effort to figure out how to construct this kind of query. I don’t know. If it’s a feature request, it doesn’t seem as big to me as SKOS-based conceptual hierarchy support (enforced nested hierarchies).

I think this will come naturally. Once Logseq has a nice search hierarchy, people will want to filter the view as well.

@boisjere

Is All This Worth It?

It bothers me that when I express the desire for these library-science types of things, people often chime in suggesting it’s a high-investment, low-return activity with fragile output.

Many of these people understand that careful note creation is important, but suggest that structured outlining over a large collection of notes somehow isn’t.

I think it is absolutely worth it. I am fighting the massively lacking Zotero system of tags and saved searches every single day. I am at the point where it is often easier for me to find items on Google Scholar than in my Zotero database.
Logseq will only make this 10x worse. A researcher might add 5 Zotero items a day, 1000 per year; in Logseq, it is easy to add 50 blocks in the same amount of time. So we are talking about 10k blocks per year of research. Over the course of a PhD, we are talking about tens of thousands of blocks, over a career hundreds of thousands. Especially as there might be tools that automatically feed into the Zotero database, such as RSS-feeds and the like.

@boisjere

I see a future where someone in their 20s today collects extensive notes for 40 years. Then they want to start writing masterworks. I think if they’ve been playing with and refining namespace OMOCs, and conceptual OMOCs all along, those will provide important pathways into their ginormous note clouds.

This isn’t foldering. These structured pathways into their graphs don’t need to be exhaustive. Not every note need be encompassed by these maps, and that’s fine.

I think you can often say about classification hierarchies what is sometimes said about plans. “Plans are useless, planning is priceless.”

When I spend time and expend intellectual effort organizing things hierarchically - essentially thinking like an outliner, but using crisp criteria over very large collections of notes, it increases my mental clarity. If at some point the hierarchy becomes useless, I’m happy to let it go stale.

I completely agree. The main reason I am looking at Logseq is that Zotero just doesn’t cut it anymore to organize the information I’ve collected.

The benefit of these hierarchies is that they are so lightweight that ignoring them or adding new hierarchies is very little effort. This is not like a folder structure, which is fixed and can only be resorted with a massive effort. Here the hierarchies are a type of overlay on the existing structure, so despite the large power, it doesn’t complicate anything for users who chose not to rely on hierarchies.

@boisjere

When I’m writing a start with an outline but as I get into the compositional flow of things the outline gets very malleable and may be abandoned altogether as a new emerging logic asserts itself.

At the same time, a meta-outline that grows resilient over time, and seems to legitimately embody the larger structure of your way of thinking, would be gold.

tl;dr - I think we have 4 feature requests here, not 3. Actually… I think there are 5 - one is hidden.

1. Namespace-based hierarchies homepage (the “Logseq namespace MOC”) autolinked from sidebar

2. Polyhierarchy support (multiple “Logseq namespace MOCs” - where children can have two parents)

3. Conceptual hierarchy (a complex query page that aggregates notes to the right nesting level in a conceptual tree on a page that has the property of being a conceptual hierarchy… ?)

4. Tree-search - a query that picks a page in a multi-page hierarchy as parent, and returns it and all its child pages.

So 1. is GUI representation, 2. is internal relationship between tags, 3. is different hierarchy views (?) and 4. is search on 1 and 4?

For the feature requests, we need to find the right balance between abstract terms and concrete examples.

While virtually everyone has used faceted search, e.g. on Amazon, only few people are familiar with the term, and abstract nonsense gets pushback.
We also need a good, concrete, example. Maybe something from literature. A book about World War 2 could be classified by

• /Books/LastName/FirstName/Title
• /Literature/Non-fiction/…
• /History/20thCentury/WW2/…
• /Military/Conflicts/WW2/…
• /Places/Europe/…
• /Technology/Weapons/…
• Any of the Library classification schemes: Dewey, UDC, LCC, Bliss, …
  • These are available from library catalogs and a plugin can tag book items automatically
  • wouldn’t it be great to be able to browse our own libraries by these schemes?
• …

All of which are completely reasonable and useful for finding the item.

We also need to explain why tagging is not sufficient, as in this case our item would need a large number of tags, forgetting to tag the item would make it irretrievable, and tags by themselves to not give the hierarchical search we need.

[gax]

Here is an example why we need to be able to record relationships between tags.
This example is just about the tagging side, it does not say much about the presentation in Logseq, other than a browsable hierarchy as the most basic use case, but many more advanced searches can be built on top of SKOS-related tags.

Historian Bob studies animals in history.
He reads the book
Ark Royal : the Life on an Aircraft Carrier at War 1939-41.

Author:	Sir William Jameson
Publisher:	Penzance : Periscope Pub., 2004.

The book has these library classifications:

• Dewey 940.545

  • Class 900 – History and geography
    • 940History of Europe

• LCC

  • World History And History Of Europe, Asia, Africa, Australia, New Zealand, Etc.
    • History (General)
    • World War II (1939-1945)
      • Naval operations
        • Anglo-German By engagement, ship, etc., A-Z

The book is tagged with Dewey:History of Europe and LCC:Anglo-German By engagement, ship, etc., A-Z. “Dewey:” is the namespace for the Dewey system, and “LCC” is the namespace for the Library of Congress Classification. These tags be added easily automatically by an improved Zotero plugin.
So just by automatically importing library classifications, we can already browse our books by the Dewey and LCC systems.

The book is also automatically classified by author last/first and year.

The book also mentions a cat Unsinkable Sam, so
Bob tags the book with animals:F. catus. This makes the book appear in a hierarchical search about animals as well.

So with very little effort (a single manually added tag so far), Logseq can already automatically generate 5 browsable hierarchies:

• /Books/ByAuthor/Jameson/William
• /Books/ByYear/2004
• /Dewey/History and geography/History of Europe
• /LCC/World History and …/History (General)/World War II … /Naval Operations/Anglo-German…
• /animals/…/…/Mammalia/…/Felinae/…/F. catus

Additionally, Bob has a few lightweight classification schemes that fit his work, so he tags the book with bob:aircraft-carriers and bob:non-fiction, this additionally makes the book available under

• /bob/military/navy/aircraft-carriers
• /bob/literature/non-fiction/

Bob told Logseq that aircraft-carriers is narrower than navy which is narrower than military, so Logseq can also generate these search hierarchies automatically.

The process is very lightweight, so Bob can easily tag individual blocks of his notes.
It does not affect the current use of tags either, so Bob does not need to classify all tags from the beginning, he doesn’t even need to use the hierarchical capabilities at all.

The Library of Congress also uses SKOS, so one gets really nice search capabilities for free:

• LCC:
  • By engagement, ship, etc., A-Z - LC Linked Data Service: Authorities and Vocabularies | Library of Congress

  • Broader Terms

    • Anglo-German

  • Narrower Terms

    • Admiral Graf Spee (Battleship)
    • Altmark (Ship)
    • Anglo-Saxon (Steamship)
    • Ark Royal (Aircraft carrier)
    • Athenia (Steamship)
    • Bismarck (Battleship)
    • Dragon (Cruiser)
    • Firedrake (Destroyer)
    • Hood (Battle cruiser)
    • Penelope (Cruiser)
    • San Demetrio (Tanker)

[boisjere]

I love this! I love the example, plus it’s more concrete, and as you say it offsets the abstract ideas.

This really makes the case for SKOS.

I wonder if we can prototype this by putting SKOS info in the page properties for this cluster of pages around Ark Royal.

In the parallel thread on hierarchies we see in the forums right now, “Using Hierarchies or Is There A Better Way”, they discuss how you can use page properties instead of namespaces to define a the parameters for a “trip” or travel page.

It’s @alex0 who gives the example. (Using Hierarchies or Is there a better Way? - #15 by alex0)

I don’t imagine there’s anything stopping us from placing SKOS fields in there. Later you might want a plugin to enforce proper sytax.

But for a prototype just for the cluster of BT, NT, RT relations around “Ark Royal”, we could probably hand-roll it, and then create some set of queries that spit out the 5 browseable hierarchies.

[alex0]

Yeah what you are looking for here is better UX for queries because once you embrance the “database” approach you can do everything mentioned here and more.

Logseq’s [[parent/child/teddy]] hierarchies are definetely not suited for this.

[boisjere]

Better UX for hierarchies is certainly one of the feature requests we’re exploring here. You are right about that @alex0. It was my own animating concern once we got started, and I still want that.

Whether it’s built on top of namespaces, or properties and queries, I myself definitely want a “Hierarchies” system link, with qualities like I’ve described above, between the “Graph view” and “All pages”.

Also, in his outstanding work on SKOS polyhierarchies in this thread, I don’t think when @gax writes things like “/Books/ByAuthor/Jameson/William”, he’s necessarily literally referring to the current [[parent/child/teddy]] style of namespaces based on page titles.

As this thread has developed, @gax has contributed ideas that are growing so rich and powerful. I would just love to implement his most recent ideas in a small test case - just to click around and see what it would feel like to navigate a small set of pages through rich/smart polyhierarchy (his “Ark Royal” example).

I don’t care if it’s using namespaces, queries, or burning corn to appease the god Moloch. Really any mechanism for experiencing this type of page traversal in Logeq would be amazingly helpful.

I want to apply outline thinking at a higher level than “indented blocks on the page”. I want “indented pages in the hierarchy”. I want to apply exactly the same kind of thinking, one level up.

[alex0]

You misread my comment, I said “better UX for queries” not hierarchies and by that I mean just embrance the “database” approach with tags and properties and ask for a better UX to query them, so that you can browse them maybe interactively with “virtual” hierarchies.

For the use cases stated above I see the current Logseq data structure to be enough but missing representation/navigation.

For example [[Parent]] can have properties like

subcategories:: [[Child 1]], [[Child 2]]
another-hierarchy-subcategories:: [[Child A]], [[Child B]]
extends:: [[X]], [[Y]]
extended-by:: [[Z]]
generalizes:: [[W]]
whatever-you-want:: ...

but what is missed is UI/UX to easily browse them, for example a simple way to say “display the complete tree of pages formed by “extends::” property”.

Think this as databases vs file systems: databases are a more general data structure so you could have different “virtual” file system extracted from the same database.

[gax]

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:
  • 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 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
    

[boisjere]

I am thinking, @alex0, that perhaps we agree on substance, but I used “hierarchy in an ambiguous way”. Thank you for your more focused description. When you wrote:

you can browse them maybe interactively with “virtual” hierarchies

That is what I want. A good UX, layered over what you describe as a database approach is great! What matters is the experience of browsing a tree, as way of traversing a subset of your graph, above the level of the page.

Conveniently, a tree = an outline, in terms of UX. Logseq already does the UX right.

In terms of UX, I wish I could edit “All pages”, “Linked references” and “Unlinked references” exactly like a standard page, in outline form, with maybe a drop-down menu specifying the query:

• So one could be the current default or flat list in reverse chronological order
• One could be according to some taxonomy or classification scheme, plus a flat list for notes outside that scheme
• One could be by project, plus a flat list for notes outside that scheme
• And you could edit those pages like normal outlines, and turn them into saved search pages

I don’t need hierarchies to be stored objects necessarily. It will be better if they are saved queries that return outline-structured, editable, saveable results. It’s good because I’d want many notes to fall within the scope of more than one tree.

• In one of my examples above, the hierarchy shows a note for [[Topics/Sexuality/Sexual Power Dynamics]].
• That note is relevant to both [[Topics/Sexuality]] and [[Topics/Psychodynamics]] Topics.
• But the reason I’m exploring it is for the novel I’m working on: [[Journals/Project Logs/Candace Valleigh]].
• As a novelist, the fire in the story comes from deep inside my psyche, so I also need to ask hard, searching questions about that topic and why it is emerging in my heart as a topic relevant to this story, so I need to do personal journaling about it. I’ll want to open my personal journal and go to that topic to work on it, when I have reflections that relate to that topic.

In each of these locations, I want that note to appear in editable, collapsible outlines.

I can do this manually, or try my luck with Unlinked References, which I cannot currently edit as an outline in and of itself. This makes it a bit of a mess, taking too long to scan visually, so I ignore it.

As a non-technical user, I just want the experience to work. I want this tool to be useful for me and for the way I think. Since it’s in early stages of development, this is a chance to have input. Also, since what I want is editable outlines, and much of what Logseq does is present interrelated blocks in editable-outline form, this seems like a promising tool.

But I want this to be a tool, not a toy. As a non-technical user, if I have to tinker with it too much, it becomes a toy. I’d play with it for the sheer delight of dancing up the learning curve, and do my real work in Scrivener or something.

I’m currently using Scrivener as a massive database for teaching the history of psychology, but the search is too slow, and the foldering is a bit too rigid - even though labels help with lateral connections a bit. It’s really not optimized to be a long term environment for grooming and improving a web of knowledge, but I can be fast in it.

There’s no such thing as “just UX” for a non-technical user. I feel comfortable in Logseq, but some founders, like those building app.capacities.io, take UX pretty seriously, and it feels good to be respected like that, as a user, and not be told to construct something that looks like code. (I’m a bit technical, but prefer GUIs for most things).

[alex0]

I get what you are trying to accomplish here, but why properties to store relations like in my example above wouldn’t be enough?

My point is that we already have the data structure in Logseq and we just need a better way to query it.

If you where able to type something like {{tree }}, for example {{tree extended-by}}, and it renders an indented list of pages linked together by the specified property (in this case “extended-by”) would it be enough for you?

For example:

Page A
...

Page B
extended-by:: [[Page A]]

{{tree extended-by}}

renders:

* Page A
    * Page B

[alex0]

@boisjere

In terms of UX, I wish I could edit “All pages”, “Linked references” and “Unlinked references” exactly like a standard page, in outline form, with maybe a drop-down menu specifying the query:

If you mean that references etc should be a special default case of what we are discussing here and should be displayed with a command, i.e.

{{linked-referencies}}
{{unlinked-referencies}}
{{namespaces}}
{{tagged-pages}}
{{tree <property>}}

then I’m totally with you.

[boisjere]

You know @gax, I think your feature request is really powerful. I would really, really, really want software that can do this with seamless UX. I am currently hacking together some of this kind of knowledge organization using these tools:

• Vocbench (http://vocbench.uniroma2.it/)
• TemaTres (Tematres: management formal representations of knowledge)
• Taguette (https://www.taguette.org/)

I’m using Vocbench and TemaTres to try and connect with existing taxonomies, and Taguette to infer my own, over my collections of notes. I am doing it for tag control.

This is exactly the point you make in your Feature Request draft. It fights tag explosion, which matters for those of us who like to maintain a synoptic overview of what our knowledgebase contains. It also surfaces knowledge, because some categorical knowledge can be inferred directly from taxonomic or categorical relations.

I don’t have anything to add really.

• You are doing a very good what and why feature request for this kind of tagging
• @alex0 is very good at explaining best ways how to do it in Logseq
• I just want to start using it.

I think that with you two doing much better work than me, my feature requests can be residual UX considerations - that queries leveraging SKOS or hand-coded trees be returned as editable outlines that can be saved as auto-updating pages. Something like that.

The best I can do is suggest how I want the thing to feel in my hands.

[boisjere]

This is tantalizing! And I guess an SKOS importer would be able to map SKOS info to this Logseq data structure?

If that is the case, your ideas about how Logseq can already handle this data extends the feature request being constructed by @gax. If there was a section in that feature request which said in more detail how Logseq is already able to handle this data, then that focuses the question.

I think the question becomes - should Logseq’s core behaviours evolve in a way that more deeply support the management of these properties, or are we left with a personal burden of constructing queries, or waiting for a plugin and hoping its development always remains up to date.

Maybe this is ultimately not a technical question, but a user question. If people - and scholarly communities - who deal with taxonomies and classification schemes frequently (academics to a degree, transnational organizations to a very significant degree), are to be supported by Logseq, it would be best to make taxonomy-management functions core.

[alex0]

And queries should definitely have more display options and not only block list and table.

For example a carousel of cards:

[gax]

@alex0

I get what you are trying to accomplish here, but why properties to store relations like in my example above wouldn’t be enough?

My point is that we already have the data structure in Logseq and we just need a better way to query it.

If you where able to type something like {{tree }}, for example {{tree extended-by}}, and it renders an indented list of pages linked together by the specified property (in this case “extended-by”) would it be enough for you?

@alex0 What I would like to do is decouple the tagging of pages from the organization of the tags themselves.

So for example, I might tag many pages with parent, child, and teddy. Over time, as the number of tags explodes, I find that I need to organize my tags, so I create a hierarchy and tell Logseq that teddy is a child node of child which is a child node of parent. I also tell Logseq that teddy is a child node of stuffedAnimal, which is a child node of toy. This automatically makes every single page tagged teddy appear in the hierarchies, without needing to edit the individual pages.

Another use case: Items imported from other systems (e.g. Zotero) have many overlapping tags, such as “History, 20th Century”, “history”, “History / World”. In practice, this creates graphs that look like this

and is practically unusable, the recommended solution being to just delete the tags (and discard the information contained in the tags).

A much better solution would be to create your own hierarchy, and then tell Logseq where the existing tags fit into your hierarchy. For example, I could search for all tags containing “history”, and place them under my history hierarchy.
This will automatically categorize all of the imported data without needing to edit any of the pages. Later, as my organizational system changes, I can move the tags around or create other hierarchies that fit my workflow.

[alex0]

Yes, I got the use case, but what you are asking for is assigning some properties to tags so that they form a hierarchy i.e. one tag has some other tags as child. And someone mentioned “polyhierarchies” or something like that because some tags may belong to different hierarchies.

I’m saying this is already possible since tags are pages and pages can have properties with the syntax:

property-name:: something, [[Page A]], URL, whatever

So you can already structure those polyhierarchies but you don’t have the UI/UX to query and display them in an efficient manner.

I.e. you can use {{query }} syntax to list pages that have certain properties but it’s not iterative, you can’t make it display

* Page A
   * Page B
        * Page C
   * Page D

when these pages are linked together by a property you define, for example “extends”, “extended-by”, “generalizes” or whatever name you want to give to each of the polyhierarchies you need.

If you don’t want to display an indented list but a graph it doesn’t matter, it’s still an UI/UX issue; no need (from what I can tell) to extends Logseq data structures.

Is it clear what I mean?

[gax]

SKOS items can have notes, which can contain images.

[gax]

@alex0

I’m saying this is already possible since tags are pages and pages can have properties with the syntax:

property-name:: something, [[Page A]], URL, whatever

So you can already structure those polyhierarchies but you don’t have the UI/UX to query and display them in an efficient manner.

@alex0 I get it, I didn’t think about tags as pages. User interface would then pull all the relationships out of the individual pages and make them editable.

[boisjere]

This is so cool @alex0 ! If it’s already possible to specify the properties we need, we’d benefit from a standard way of doing it, so we can enjoy all the benefits of the large feature request @gax was drafting. Also, an SKOS-properties standard in Logseq would be a draw for many people.

And of course, people not interested in this could ignore the whole thing.

[gax]

I’ve created a feature request: Knowledge Management for Tags / Tag Hierarchies

[boisjere]

Hey @pvb, I just checked out Trillium and I agree!

• a) it beautifully handles a tree-based organization with the ability to access clones of a note of on different branches in the tree
• b) it sucks that it’s implemented in sqlite. Logseq achieves a better separation of data from behaviour.

Also, even though I’ve been pushing hard for a more hierarchical way to traverse my graph, Trillium seems a bit too rigidly hierarchical. What I really want is a flexible graph, with lots of ways to traverse it - including a tree-constrained manner of doing it for content that is naturally connected that way.

I only want to put info into tree format that is helpfully organized that way. I don’t want to be prevented from doing that, but I don’t want to be forced to do it either.