Properties and bases: a table view of your notes
Write key:: value lines in any note and Dexi turns them into typed properties. A base is a saved table or card view over the notes that match a filter, sorted how you like — the same idea as Obsidian Bases, and .base files import directly.
Sometimes a stack of notes wants to be a table. A reading list with a status and a rating. Job applications with a company, a stage and a next date. Recipes with a cuisine and a cook time. Dexi has never had a properties panel or a schema to set up first, and it still doesn’t: a property is a line you type.
Write status:: reading on its own line, anywhere in the body, and the note now has a property called status with the value reading. due:: 2026-09-10 becomes a date, rating:: 4 a number, authors:: [Kahneman, Tversky] a list, ref:: [[Thinking, Fast and Slow]] a link. Dexi reads the type from the shape of what you wrote, so there is nothing to declare. A base is where those lines pay off: a saved view — table or cards — of every note that matches a filter, sorted how you like, with the properties as columns.
Why it matters
Properties are prose, which keeps them cheap. There’s no form to fill in and no field to add to a template before you can use it, and the line stays visible in the note where you wrote it, so a note read on its own still makes sense. Keys are forgiving — Due Date:: and due_date:: are the same property — and a value that looks like a date, a number, true/false, a #tag or a [[wiki link]] is treated as one. Property lines stay in full-text and semantic search, so author:: Kahneman is still found by searching for Kahneman. Lines that only look like properties — std::vector, a URL, a quoted > reply:: — are left alone.
A base is a saved question over your notes. Its filters can use your own properties and the things Dexi already knows about every note: title, tags, links, folder, source (typed, bookmark, email, feed), domain, created and updated dates, whether a teammate shared it. Conditions combine with and, or and not, sorts stack up to five deep, and one base can hold several views — the same reading list as a table sorted by rating and as cards showing each page’s preview image. Bases run over everything you can see, including notes teammates have shared with you, and they’re personal: nobody else sees your bases or how you’ve set them up. Every base is also available to your AI assistant — a connected Claude can run “my reading list” or “what’s due this week” through the MCP server instead of reconstructing the filter. If you’ve built Bases in Obsidian, the filter language is the same subset you already know and a .base file imports as-is; formulas, group-by and summaries aren’t here yet, and an import tells you exactly what it left out rather than dropping it silently.
Who gets the most out of it
- Readers with a queue — A reading list is the canonical base: a status, a rating and a date finished, next to the page’s own description and preview image that came in with the bookmark.
- Job seekers and freelancers — Company, stage, next step, contact — one line each in the note you already keep, and a table of open applications or proposals that sorts itself by next date.
- Students and researchers — Papers with an author, year, venue and verdict become a literature table you can filter to “unread”, sort by year, and export alongside your Markdown.
- Obsidian users — The same key:: value syntax and the same Bases filter language, with your .base files importing directly — running over bookmarks, forwarded newsletters and feed articles as well as typed notes.
Example: A reading list that keeps itself
You bookmark a lot of long articles and lose track of which ones you’ve actually read. You decide to give the queue a table.
- You open a saved article and add two lines at the top of the note: status:: unread and topic:: #pricing. The editor highlights the status:: prefix, so you can see it was recognized as a property. From now on each article you clip gets the same two lines.
- In the sidebar, next to Bases, you click the plus and name the new base Reading list. It opens as an empty table. Under Filter you add one condition — status is not done — and under Columns you pick Title, status, topic, Domain and Updated.
- You add a second view, choose Cards, set the image property to Preview and pick a card size. The same queue is now a wall of article thumbnails.
- Back in the table you sort by Updated, newest first, then by topic, and set a limit of 50 so the view stays a queue rather than an archive. Each change saves to the base as you make it.
- When you finish an article you change its line to status:: done and it drops out of the view. Add rating:: 4 beneath it and rating appears in the column picker for every view, ready to sort on.
- In Claude, connected through the MCP server, you ask what’s on your reading list about pricing. It runs the Reading list base and answers from the entries tagged #pricing, properties included.
- Months later you export the base as a .base file — the format Obsidian uses — to keep next to your Markdown export, or to open the same view in a vault.
Two typed lines per note and one saved view, and the queue takes care of itself.
Try it in your own workspace — free, no credit card required.
Get started