Designing a query language

I’m starting this thread to collect ideas for what a first class query language over a set of org-roam notes might look like. Some kinds of capabilities/questions I personally like to see:

  • Typical nested boolean logic-style combinations (and, or, not)
  • A “links to X, up to depth N” predicate
  • A “links from X, up to depth N” predicate
  • Filtering on tags

Additionally, and perhaps this is a separate topic, I think some kind of fuzzy/approximate matching would be great. In my ideal world I’d be incrementally training some ML system to serve up things I might not have thought to link together, where depending on my needs I can crank a “noise” dial up or down.

2 Likes

Thinking about this a bit further, maybe what we really want is a first class graph query language. I haven’t looked into graphql yet, but perhaps this would be a good place to start.

Correct me if I’m wrong but graph ql doesn’t take do that. Not surprisingly at this point, the graph query language isn’t really about querying graphs but about standardizing the various ways people query entities. There is no way to say “all notes less than three links away from foo”

I would maybe look to the graph databases like neo4j for inspiration

1 Like

Neo4j can do that. So can Gremlin, which is cross-platform.

Building on the idea of “show me any successor (or predecessor) within N links of file F”, it would be nice to be able to say “given a set Fs of files satisfying some search, show me any sucessor (or predecessor) within N links from anything in F”.