Interfaces for adjusting a query

Last updated April 7, 2023

#Question

Not all edits to the query have to be within the query editor. In Provide Push and Pull as inline syntax to affect the related items section for a page, we outlined how push and pull work as an inline DSL to add to a related items query’s any clause.

Generative AI can provide natural language as an interface. Simply describe what you’d like to query, and the large language model will write the query.

User behavior within a well-designed choice architecture can be a signal of preferences. We can see how this happens with newsfeed management mechanisms. As people are looking through the results of a query, they might right click then select the option: “remove from query.” The menu path might look like the following, giving the option to remove the specific item, nodes from that author, or nodes discussing shared topics.

1
2
3
4
{:remove {:itemID sladfkji4af4sdkf
          :author "John Doe"
          :topic-mentioned ["topic1"
                            "topic2"]}}

When people click on an “x” on the query result’s item, the smart default could be to remove that block’s UID from the query through (not (any: uid1 uid2)).

Imagine “economic inflation” were a topic mentioned in an item within your newsfeed query and you right clicked to remove that topic. This might translate into the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
(def muted-topics-list
  (any: "economic inflation"
        "veganism"))
(def muted-items-list
  (any: uid1
        uid2))
(def newsfeed
  (any: followed-people
        followed-interests)
  (not: (any: muted-authors-list
              muted-topics-list
              muted-items-list)))              

Alternatively, users might process the list of query results through highlighting and lowlighting. Highlighted and lowlighted search results map to how well results map to intentions, so the default assumption could be that lowlighting a block would remove that block from the query results. A block id would then have a queries-where-highlighted and queries-where-lowlighted property, listing the relevant queries.

It’s possible that users don’t always want to reify an entirely new query as an entity, and sometimes would like to simply filter a query. Given the compositional nature of the language I’m proposing, it should come as no surprise that we can apply a filter function to any list of query results.

1
2
3
4
5
(query:
 newsfeed
 (any: "behavioral economics"
       "web3")
 (not: "regulation"))

Roam has a GUI for manipulating these filters that can go beyond the language interface described above. For example, below, I’m filtering all linked references to [Rob Haisfield](Rob%20Haisfield) for [CLM](CLM) (claims) and [EVD](EVD) (evidence) that are connected.

If written in my proposed query syntax, this would look like the query below. An all: operator is assumed at the beginning of the query.

1
2
3
(query: "Rob Haisfield"
       "CLM"
       "EVD")

Scaling Synthesis

Interfaces for adjusting a query

Backlinks