Are subqueries possible in Logseq?

Can I use subqueries in Logseq? " A subquery is a query that appears inside another query statement." I’m trying to return all blocks linked to pages with specific properties. Is that even possible? I want to make sure it’s not already feasible through Advanced queries before I make a Feature Request.

1 Like

See Link Discord

1 Like

Thanks for digging that up @Rhantismos23!

Here’s the image that @alex0 shared (for those who don’t use Discord):

Thank you @Rhantismos23 and @Ramses . @alex0 's tip is very clever and I’m definitely using it but it’s not quite the application I had in mind. With @alex0 's table, you have to know the exact structure you want in advance so that you tag each author with books:: query embed. It wouldn’t make sense to do so for complex concepts such as: show me all symphonies composed by people born in Autria or show me all people with blue eyes who give Logseq advice. For spontaneous thoughts like these, you would need Logseq queries to reach into the meta-metadata (links themselves linked to something else) and draw these advanced connections.

1 Like

So it’s not a matter of visualization but of filtering results… did you look at Advanced Queries? I don’t know Datalog to point you to a solution but your use case is exactly why query languages exist on the first place.

Absolutely! Do you think Advanced Queries could allow me to do such a thing? If so, I’ll gladly dive into it and take time to learn it. I just need a more experienced user to tell me it’s possible.

Maybe @cldwalker could tell you if queries like “show me all symphonies composed by people born in Austria” are possible.

A bit off topic but I hope in the future we will have a self-explanatory syntax for simple queries like this one:

[[type:: book]] [[type:: quote]]
+
[[author:: *]]
  [[born:: [[1700]]-[[1800]] ]]

(for reference, it’s supposed to mean “books or quotes by authors born between 1700 and 1800”).

100% Simple queries likes these (no pun intended) shouldn’t require a bunch of code. All it does is alienate a bunch of people who are interested in PKM and but not so much in programming per se. Logseq should make it more accessible. I’m all for simple syntax!

P.S. To push it one step further (quite literally), what about “show me all books or quotes by authors born in a developing country”? That’s a 3-levels-deep query that draws the dots between the country’s properties (i.e. status), the author’s properties (i.e. place of birth) and the book’s properties (i.e. author). Try and do that with Logseq’s current structure…

Do you think we could make it into a Feature Request?

You were on point there. @FTWynn showed me that it is in fact possible. Take a look at this beautiful query. My mind is blown! The implications for PKM the way I envision it are huge, provided I can go as many-levels deep as possible. Thank you so much to all of you guys! I hope I can give back to the community in the near future.

1 Like

Let’s make an experiment: I will explain my syntax with some examples and you will try to write your query with it.

I. OR, AND and NOT operators are inspired by Boolen Algebra syntax i.e. + for AND, for OR (usually omitted) and ' for NOT. They are evaluated in this order: ', , +.

[[Books]] [[Quotes]] + [[Oscar Wilde]]
Books or quotes by Oscar Wilde

II. To specify that a [[page]] must be a property value it uses the [[property:: value]] syntax and a * as value to say “any”:

[[author:: Oscar Wilde]]
Everything that has Oscar Wilde as author

[[type:: book]] + [[author:: *]]
Every book that has an author

III. Use multiline (to enable indentation):

[[Books]] [[Quotes]]
+
[[Oscar Wilde]]

IV. Use indentation to specify more properties referring to the parent line, particullarly useful with [[property:: *]]:

[[Books]] [[Quotes]]
+
[[author:: *]]
    [[nationality:: Italy]]

V. Use - as “between” two values of an ordered set:

[[Books]] [[Quotes]]
+
[[author:: *]]
    [[nationality:: Italy]]
    + [[birthday:: [[1700]]-[[1800]] ]]
1 Like

Love your syntax! Logseq would really benefit from it in terms of being user friendly. I hate that I’m going to have to learn Datalog and go through Advanced Queries to do advanced filtering on the fly but oh well… I will keep you posted!

Related thought (might be off-topic): you know how the simple filter of Linked Reference is a dynamic feature that narrows down the amount of tags as you select more and more of them because you’re narrowing down the list of blocks? How crazy would it be to have a view of all properties in your graph on your home page, say, and select “Italy” as a nationality only to see a bunch of other properties disappear because they is no movie or music composed by an Italian in your database but books remains because you have a book entry written by Oscar Wilde and a recipe by some Italian chef. It’s called faceted search (used by Amazon among others) and is a killer feature that guides you into a very specific combination of things that you wouldn’t have thought about otherwise. What we need is more like an Advanced Filter rather than Advanced Query.

Why is it useful in the context of a digital second brain? Sometimes you don’t know exactly what you’re looking for and you’re just looking for connections to make. You avoid wasting your time and making up arbitrary queries which amounts in 0 results so you intentionally keep it broad to avoid dead ends. How are you supposed to know that there’s musician out there in your database which also happens to teach philosophy and has a famous sister unless you make that arbitrary query and get lucky with that one result (not very likely). As ti stands in Logseq, you have to know what you’re looking for in advance, even with Advanced Queries, and theres very little room for exploration apart from navigating blindely from one page to another and forget why you got there in the first place. The capacity for abstraction is the most powerful tool we have as human beings and I’ve yet to find a solution that does it justice.

Anyhow, I’m rambling…thank you for your interest! Let me know what you think. Logseq users are very passionate about making it the ultimate solution, which is great!

This is exactly why I wrote this proposal to use properties as indications to traverse the graph and present that tree structure in different ways:

We could even concatenate more properties:: as indications, for example genre::, year:: and artist:: to browse music albums starting from genre folders, then years and then by artist:

{{tree genre year artist}}
{{folders genre year artist}}

to print an indented list or folders and subfolders.

This way you define one time the best way to browse a certain part of your graph and use it multiple times instead of writing complex queries everytime you are looking for something.

The browsing experience would be as natural as using a file manager.