Distinguishing between elements that have the same name

Questions & Help
1

Hi,

Background

I’ve been using Logseq for about one and half year, and I have tried several approaches of categorizing information. I am now trying to build a comprehensive taxonomy for my PKMS and organize my notes around that taxonomy.

Question:

I am seeking feedback / advice on the naming conventions and / or metadata to use for terms or concepts that have the same name but different meaning or they have the same meaning but my relationship with them is different. I will go through a few examples to illustrate the issue

Elements with the same name but belonging to different topics

For example, there is Celery the veggie and Celery the distributed processing engine. One approach that I have thought of using is Celery (Vegetable) and Celery (Technology) to distinguish between the two

Terms with same name but one corresponds to a topic and the other to a physical object

For example, Scion TC 2005 :

  • Is a car model for which I want to capture knowledge such as engine information.
  • At the same time, it is my car, and for that I want to track TO-DOs, mechanical work that has been done etc.
    The approach I’ve though for that is to have an additional property (e.g., `Inventory’:: Yes) or an additional tag e.g., [[asset]]
    This distinction will help when trying to filter for information pertaining to either topics.

Elements that correspond the same entity, but my relationships with them is different

An example here is the company ABC Widgets. That company produces widgets for which I want to capture knowledge about but at the same time they are a client of mine and I want to track TO-DOs related to my work for that client.
A potential approach here is to add a tag such as [[client-work]] or a property is_client:: Yes

I would appreciate your thoughts!

2

The primary means for disambiguation between same-name concepts is namespaces.

  • Read Hierarchical tag system
    • Ignore hierarchy, read namespaces.
  • Your examples could become:
    • vegetable/celery and technology/celery
      • or veggie/celery and engine/celery
    • model/Scion TC 2005 and asset/Scion TC 2005
      • or topic/Scion TC 2005 and object/Scion TC 2005
    • company/ABC Widgets and client/ABC Widgets
  • In other words:
    • the right part is the common name
    • the left part is the family name
      • Prefer family names that group concepts conveniently.
1 Like
3

Thanks a lot @mentaloid !

I thought of namespaces before, and even they provide a simple solution to the problem, I think that later on (and for cases I am probably not aware of right now), they might make querying more difficult or more complex. For example, if I want to retrieve information across namespaces where ABC Widgets exists, I need to manually enter each node of the tree e.g., company/ABC Widgets and client/ABC Widgets etc. in my query.

That’s why I was considering a property or a tag-based approach.

4
  • That’s NOT the case.
    • Querying namespaces is not particularly difficult.
      • You just have to enter a single entry with :block/namespace
      • In contrast, the parenthesis option makes the namespace a part of the name, resulting in both harder and slower querying.
  • If you somehow find a valid reason to reject namespaces, the next best option is an approach that imitates namespaces, i.e. a property namespace::
  • Should not construct a tree. Just use an additional level, and only when needed.
1 Like
5

Thanks again for the response. I really appreciate it.

If I understand correctly what you are saying here:

Querying namespaces is not particularly difficult.
You just have to enter a single entry with :block/namespace

I would construct an advanced query that will traverse all namespaces and find all matches with the “leaf node” name e.g., Scion TC 2005 in one of the aforementioned examples. (I am kinda struggling with advanced queries, but it’s useful to know that there is at least this option to retrieve information across namespaces)

6
  • Yes, the information is retrievable.
  • You don’t have to traverse all namespaces.
    • :block/namespace targets directly each node
    • (namespace does the same in simple queries
1 Like
7

You can also add aliases to your namespaced pages. That way, you can maintain your categorical hierarchy, but also be able to reference your pages easily inline. With some quick testing, I think aliases are resolved properly when searching, too.

For example, I have a page tech/logging/tracing for info about trace logging. I have it aliased as tracelog, which is how I reference it inline.

1 Like
8

Thank you both for the help!