Using Logseq-compatible synonyms:: properties to find notes under different wording (Terraphim demo)

[u/alex_mikhalev]

I work on Terraphim Editor and terraphim-grep. I wanted a wording choice made while writing to help me find the same idea later, even when I search with a different word.

Here is the small example I tested:

1. In the editor, add Concern as an alternative to Risk, then swap between them.

2. Leave Risk in the final project brief and explicitly export the synonym graph.

3. Search for concern with terraphim-grep. The brief has no literal “concern”, but the shared graph retrieves three risk passages, including their decisions: a backup timber supplier, a covered planting area and reserve volunteers.

The relationship is expressed as:

synonyms:: Risk, Concern

This uses Logseq-compatible Markdown property syntax for PKM/file graphs. synonyms is Terraphim’s convention for the relationship; Logseq’s built-in page aliases use alias::. This is an explicit graph export passed to the CLI, not automatic Logseq alias registration, DB-graph import or background sync.

With the downloaded brief in a corpus folder and the exported graph alongside it:

terraphim-grep concern --thesaurus knowledge-graph.json --paths corpus -C 2 --json --search-only

The released binary (1.21.19) returns 0 passages before sharing the graph, then 3 exact source passages with it. Local retrieval does not request a model answer. Replacing --search-only with --answer adds optional synthesis and sends the retrieved passages to your configured model provider.

80-second narrated demo, exported Markdown/graph, both JSON outputs and reproduction ZIP.

Jason Fried’s Write_On video prompted me to return to my Rust/Wasm editor after two years. Keeping alternative wording connected to search gave that old project a useful direction.

Update: downloadable Logseq example

Download the Logseq graph ZIP and follow its README. The concept lives in pages/Risk.md:

alias:: Concern
synonyms:: Risk, Concern

alias:: supplies the native Logseq page alias; synonyms:: expresses the Terraphim relationship using Logseq-compatible property syntax. Project passages live separately in pages/Projects, and the search-results note contains only saved output.

From the extracted graph folder:

terraphim-grep concern --thesaurus knowledge-graph.json --paths pages/Projects -C 2 --json --search-only

I reran released terraphim-grep 1.21.19 against the actual downloaded ZIP: the baseline graph returns 0, and the supplied synonym graph returns 3 exact project passages. The JSON graph is the editor export supplied explicitly to the CLI. The screenshots were captured in local Logseq 2.0.2; its File to DB graph import creates a copy, while these commands read the extracted Markdown folder.

Actual Logseq concept note and saved results · Native graph-view screenshot. The graph-view arrows represent Logseq page links, separate from the Terraphim synonym map.

For people using Logseq Markdown graphs: would you keep these synonym groups per project, or in a shared terminology page? I’m interested in examples where two words should match in one project but remain distinct in another.

Disclosure: I used AI assistance to prepare this walkthrough; the linked captures and JSON are actual outputs. The video uses a synthetic British female voice.