Allow to use more Clojure functions in Advanced Queries (akin to Datomic; graph traversal)

[laso]

Hello,
Logseq already offers a lot of flexibility by using advanced queries. I would like to unleash more of its hidden powers by doing page graph traversal and searches with queries. Hiearchies often are too one-dimensional.

Take an example, what I mean with graph traversal:

Tienson Qin --develops--> Logseq <--partOf--   discuss.logseq.com
^             ^           ^         ^          ^
page        < property    page      property > page

When there’s need to find everything related about Logseq, we search for [[discuss.logseq.com]], but query now also finds things from [[Tienson Qin]].

Logseq lays the groundwork to do so:

• use recursion in queries to get visit linked pages
• Logseq properties can map relations between pages

Sets are used in internally in many places of Datalog attributes, but currently capabilities are limited to deal with them in queries - one existing function is contains?.

I think, what is still left is to allow to use more clojure collection functions from clojure.core & Co.
In particular I need to add (clojure.core/conj) or remove (clojure.core/disj) items from a set, which contains excluded or already visited pages. Also properties are constructed out of maps and sets, which currently are difficult to process - core collection functions would come handy here. One is clojure.core/set? to check, if a property value is a single value or set.

Proposal:
allow all or at least all collection-related functions from clojure.core (or other namespaces) to be used in advanced queries, similar to Datomic:

Datomic provides the following built-in expression functions and predicates:
[…]
All of the functions from the clojure.core namespace of Clojure, except eval.

docs.datomic.com

Function names outside clojure.core need to be fully qualified. Datomic will automatically require the namespace for a query function.

docs.datomic.com

[alex0]

Related:

Specify and display relations between pages/tags

Premise Following the discussion here I think I have a viable and concise proposal to address most use cases of the “hierarchically organize pages/tags”. The point is specifying hierarchies using page properties. For me the ideal would some syntax that, given an arbitrary user-defined <property>, (for example extends::), looks like this: Specify relations between pages Parent.md <property>:: [[Child]] Child.md <property>:: [[Teddy]] Display these relations Tree {{tree <p…

[laso]

That certainly is an interesting feature in the future.
For now I am fine with just whitelisting (all) clojure functions - with a bit of luck a relative simple change.

I then might be able to come up with and share advanced queries for graph searching, like returning all reachable pages from given page X, transitive closure and so on.

Thinking of it, this could be an alternative to Logseq namespaces:

• Namespace are suited for strict hierarchies.
• Page relations via properties allow to model either non- or not strictly hiearchical relations and relations with multiple parents (think of namespace as only allowing one parent).
• Replace long page links some/long/namespaced/page/reference in the editor, same for file names

[alex0]

@laso

Thinking of it, this could be an alternative to Logseq namespaces:

Yes! This is exactly the intention of my proposal but in the meanwhile I found very convenient to structure complex hierarchies using the outliner as I explained here:

Different ways to structure data

There is another way to organize pages and it is my favourite so far because it scales well with very long complex “poly-hierarchies”: You can write indexes like the following where you want: - [[Index]] - [[Foo parent]] - [[ Foo child]] - [[Bar parent]] - [[Bar child]] Then when you are on a page and you want to see where it is in one or more indexes, use {{query (and <%current page%> [[Index]])}} You will be able to browse the hierarchy without leaving the page. You can creat…

[laso]

Today I missed clojure.core/first and clojure.core/rest.

Is there any reason to not just whitelist all Clojure functions in advanced queries?