[DB version] Separating classes and pages when retrieving them

Testing the DB version, I have noticed that “pages” and “classes” are different concepts, but seem to be the same entity. When you configure a #class, you will see it shows two sections of properties: as a page, and as class.

imagen

This perpetuates a problem that already exists in the current Logseq, when you want to use the same name for a concept and for a class (or type of entity). For example, I want to be able to:

  • Use #book class for a block or a page that represents a specific book, as in: “Alice in Wonderland #book
  • Use [[book]] page for the general concept of books, as in: “I’m thinking of writing a [[book]]” or “The best gift I got today is a [[book]]”

The problem comes when I want to see all the references to the concept, but not all the entities classified as books. Or vice versa. It’s not possible: they all appear mixed in the “linked references” section and in the queries.

As I said, this is issue is already present in the current version of Logseq. As #this and [[this]] are the same, whenever I want to differentiate something as a class, I need to do things like #book (for the general concept) and #book-class (for the class or object type). Ugly stuff.

This is what comes to mind as possible solutions:

  1. Allow classes and pages to co-exist as totally different entities, so they can even have the same name without conflict.
  2. Just add a way to filter by “classes only” and “pages only” (and “both / no filter”) in the linked references section and in queries.

Have you found this limitation? Is there another way of solving it?

  • Specifically classified entities are called instances.
  • I’m personally against using the same name for different things.
    • this is solution 1
  • Filtering is needed anyway.
    • this is solution 2
    • but as fully customizable queries

Wouldn’t be simplier if the words with initial # were only and ever for tags, and names without initial # (but [[brackets]] instead) for pages?

I guess that the DB version tries to not overlap the existing things. But an easy change like that would be the logical solution, wouldn’t it?

Just one symbol for every different thing. No confusion.

1 Like

Wouldn’t be simplier if the words with initial # were only and ever for tags, and names without initial # (but [[brackets]] instead) for pages?

Yeah, that’s the first option I suggested. Not sure if there is a reason not to do that. Maybe backwards compatibility?

Certainly backward compatibility is a major issue. Many of us have been using Logseq for several years now, treating # and [[ interchangeably. It would be impossible for us to untangle our graphs at this point. (Nor am I convinced that much would be gained by doing so.)

A solution that might work for you now, using the existing capabilities of Logseq, is to use namespaces/hierarchy. Use “c” for class as in [[c/book]] to distinguish it from [[book]] the concept. I believe such use cases (differentiating two uses of a term) are why the namespace/hierarchy feature was added in the first place.