Bestandsformaat-referentie

Laatst bijgewerkt: 2026-07-17

Deze pagina is het exacte, op-de-schijf-contract voor elk bestand in een Plainva-vault. Ze is zo geschreven dat een tool — een ander programma, script of KI-assistent — vault-bestanden rechtstreeks kan lezen en veilig bewerken, zonder de omweg via Plainva’s gebruikersinterface. Gebruik je alleen de app, dan heb je deze pagina nooit nodig; de overige handleidingpagina’s behandelen normaal gebruik.

Alles hier is puur UTF-8-tekst. Notities zijn Markdown met YAML-frontmatter; databases zijn YAML. Niets is eigendomsrechtelijk, niets is verborgen.

Grondregels (eerst lezen)

1. De notitie is de bron van waarheid. Een .base is alleen een weergave. Eigenschaps-waarden staan in de frontmatter van de individuele notities — nooit in de .base. Om een waarde te wijzigen, bewerk je de notitie.
2. Notities blijven Obsidian-native. Schrijf in notitie-frontmatter uitsluitend eenvoudige scalars en lijsten (string, getal, boolean, ISO-datum, YAML-lijst). Schrijf nooit een genest object of een “actief/geselecteerd”-vlag in een notitie.
3. Een .base gebruikt alleen Obsidians vier top-level sleutels (filters, formulas, properties, views). Elke andere top-level sleutel zorgt ervoor dat Obsidian het hele bestand afwijst. Alle Plainva-specifieke data staat onder geneste plainva:-subsleutels.
4. Bewaar wat je niet begrijpt. Onbekende sleutels moeten een lees-/schrijfronde ongewijzigd doorstaan. “Ruim” geen sleutels op die je niet herkent.
5. Schrijf UTF-8 zonder BOM, met LF-regeleinden.

De vault in vogelvlucht

Een vault is een gewone map. De bestandstypen die je tegenkomt:

De gereserveerde namen index.md en log.md zijn nooit gewone notities; maak onder die namen geen gewone inhoud aan.

Notities (.md)

Een notitie is een Markdown-bestand. Een optioneel YAML-frontmatterblok (tussen twee ----regels) helemaal bovenaan bevat de eigenschappen; daarna volgt de Markdown-tekst.

---
type: Note
okf_version: "0.1"
tags: [project, active]
status: In progress
due: 2026-07-20
plainva:
  icon: "🚀"
  header_color: "#2f6f6f"
---
# My Project

A **bold** thought that links to [[Another Note]].

- [ ] First task

OKF-frontmattervelden

Plainva volgt OKF (Open Knowledge Format), een minimale conventie. Twee top-level velden:

Een bestand zonder type opent nog steeds prima; het is alleen “niet OKF-conform”. Een ontbrekende okf_version alleen is geen overtreding. Als je een nieuwe notitie aanmaakt, is het goede praktijk om type (en okf_version) toe te voegen. Zie OKF voor de volledige onderbouwing.

Serialisatie van eigenschapswaarden

Elke frontmatter-sleutel is één eigenschap. Schrijf de waarde in de native YAML-vorm voor het type ervan:

De “actieve” waarde van een Selectie-/Status-eigenschap is precies die platte scalar. Het palet van toegestane opties en hun kleuren staan niet in de notitie — ze staan in de regerende .base (zie Opties en kleuren). Zo blijft de notitie 100% Obsidian-native.

Zet wiki-linkwaarden tussen aanhalingstekens ("[[X]]"). Ongequote [[X]] is in YAML een flow-sequence en wordt niet geparst zoals bedoeld.

De plainva:-namespace in notities

Plainva-specifieke extra’s voor notities zijn gebundeld onder één enkele plainva:-sleutel, zodat andere editors ze kunnen negeren:

Ze zijn allemaal optioneel. Schrijf je er geen enkele, laat dan de plainva:-sleutel helemaal weg. Ongeldige waarden worden bij het lezen genegeerd, nooit als fout behandeld.

pim is het anker van de PIM-integraties (zie Agenda & externe taken en E-mail vastleggen). Het is een kleine mapping die Plainva schrijft wanneer een notitie een extern object spiegelt: uid plus account, en afhankelijk van het soort calendar (vergadernotities), kind: task + list (gesynchroniseerde taken) of kind: email + mailbox (vastgelegde e-mails). Tools moeten hem ongewijzigd bewaren; verwijderen ontkoppelt de notitie alleen van het externe object (er wordt extern niets verwijderd). Voorbeeld:

plainva:
  pim:
    kind: task
    uid: MTIzNDU2
    account: 3f9c21ab
    list: MDEyMzQ1

templateFor is het veldcontract van de sjabloontoewijzing (zie Databases (.base)): op een notitie in de sjablonenmap vermeldt het de databases waarvan het Item-menu het sjabloon standaard toont. Waarden zijn volledige wiki-links inclusief de .base-extensie — bare ("[[Tasks.base]]" komt overeen met het bestand met die naam in elke map, waardoor het een zuivere mapverplaatsing overleeft) of padgekwalificeerd ("[[Projekte/Tasks.base]]" komt overeen met precies dat pad). Plainva schrijft bare links en kwalificeert alleen wanneer er twee gelijknamige .base-bestanden bestaan. Een scalar in plaats van een lijst wordt getolereerd. Wanneer een item vanuit het sjabloon wordt aangemaakt, wordt templateFor — in tegenstelling tot de andere plainva:-sleutels — niet naar de nieuwe notitie gekopieerd.

Links

• Wiki-link: [[Notitienaam]] — vault-breed opgelost via de notitienaam. Met een kop-anker: [[Notitie#Sectie]]. Met weergavetekst: [[Notitie|getoonde tekst]].
• Markdown-link: [tekst](relatief/pad.md) werkt ook.
• Backlinks worden automatisch afgeleid, ook uit frontmatter-wiki-links (dat is wat relaties als backlinks laat verschijnen).

Databases (.base)

Een .base-bestand is YAML. Het bewaart een weergave over notities — welke notities (bronnen), hoe ze worden getoond (weergaven), hoe er wordt gefilterd en gesorteerd, en het kolomschema. Het bewaart geen notitiewaarden. Het formaat is compatibel met Obsidians Bases-plugin.

Harde regels — bij een overtreding wijst Obsidian het hele bestand af

• Alleen deze top-level sleutels: filters, formulas, properties, views. Voeg nooit een andere top-level sleutel toe. (Historisch brak een top-level columns:-sleutel elk bestand — herintroduceer dat patroon niet.)
• Elke weergave heeft een niet-lege string-name.
• Een filters-object draagt op elk niveau exact één van and / or / not — nooit twee naast elkaar.

Plainva zelf herstelt oudere bestanden die tegen de laatste twee regels ingaan de volgende keer dat ze worden opgeslagen, maar een tool die rechtstreeks schrijft moet ze meteen goed hebben.

Eigenschaps-identifiers: wanneer het note.-voorvoegsel gebruiken

Dit is de bekende valkuil, dus expliciet:

Vuistregel: de Obsidian-gerichte structurele velden gebruiken note.<key> (en file.<x> voor ingebouwde velden zoals file.name, file.folder, file.mtime); alles binnen een filterformule of een plainva-blok gebruikt de bare frontmatter-sleutel.

Top-level sleutels

• filters — welke notities tot deze database behoren. In Plainva staan hier alleen de bronnen (map/tag); eigenschaps-filtervoorwaarden worden per weergave opgeslagen onder views[i].filters. Zie Filters.
• properties — het kolomschema, geïndexeerd op eigenschaps-id. Native Obsidian-subsleutels zoals displayName (kolomkoplabel) zijn toegestaan en blijven behouden; alle Plainva-rijkdom staat onder properties[id].plainva.
• views — een geordende lijst van weergaven. Elke heeft een name en een type nodig.
• formulas — een Obsidian-functie. Plainva maakt deze niet aan, maar bewaart ze ongewijzigd.

De plainva:-subsleutelkaart

Alles wat Plainva-specifiek is, is namespaced. Drie plekken:

properties[<note.key>].plainva — per kolom:

views[i].plainva — per weergave:

Naast het plainva-blok kan een weergave een native views[i].filters-object dragen — de filters per weergave (dezelfde eenwortelige and/or/not-grammatica als het dossierwijde filters). Plainva slaat hier eigenschaps-filterregels op, één set per weergave, zodat elke weergave onafhankelijk filtert; het dossierwijde filters behoudt dan alleen de bronnen. Obsidian past views[i].filters native per weergave toe.

views[0].plainva — dossierwijde sleutels, alleen toegestaan op de eerste weergave:

contextFilters is Plainva’s equivalent van Notions “this page”-filter. Elk item is een eigenschapssleutel; wanneer de database in een notitie is ingesloten, worden de rijen ervan via die eigenschap afgestemd op die host-notitie (opgelost via de linkindex — een eigenschap die de link bezit of een gewone linkeigenschap komt overeen met rijen die naar de host verwijzen, een berekende omgekeerde kolom komt overeen met waarnaar de host zelf verwijst). Het wordt bewust niet in de native filters geschreven, dus negeert Obsidian het en toont alle rijen; ook los geopend in Plainva wordt het genegeerd (geen host) en toont de weergave alle rijen. Meerdere items worden met EN gecombineerd.

Invoertypen

plainva.input is een van:

text  number  checkbox  date  datetime
select  status  multiselect
list  tags  url  email  phone
relation

Een berekende omgekeerde kolom heeft geen input — ze wordt uitsluitend gekenmerkt door reverseOf.

Opties en kleuren

Selectie-/Status-/Multiselectie-kolommen kunnen een gecureerde optielijst dragen. Elke optie:

options:
  - value: Open          # required
    color: amber         # optional palette name (see below)
    group: Active        # optional; STATUS only — orders options into stages
  - value: Done
    color: green
    group: Closed

color is een paletnaam, geen CSS-kleur. Geldige namen: gray, teal, blue, green, amber, coral, purple, pink. Een onbekende kleur valt terug op een uit de waarde afgeleide kleur.

Weergavetypen

views[i].type is op de schijf een native Obsidian-type. Plainva-only weergaven worden geschreven als type: table plus een plainva.render-hint, zodat Obsidian ze degradeert tot een gewone tabel:

Filters

filters selecteert welke notities in de database zitten en grenst ze af.

Bronvoorwaarden bepalen het lidmaatschap:

• Map: file.folder == "Path/To/Folder" (vault-relatief; de rootmap is "").
• Tag: file.hasTag("project") (zonder voorloop-#).

Meerdere bronnen zijn gewoon meerdere items. Helemaal geen filters = elke notitie in de vault.

Waar eigenschapsvoorwaarden staan: op dossierniveau geldt filters voor elke weergave. Plainva slaat eigenschaps-filterregels in plaats daarvan per weergave op in views[i].filters (dezelfde eenwortelige structuur) en behoudt op dossierniveau alleen de bronnen, zodat elke weergave onafhankelijk kan filteren. Beide zijn geldig voor Obsidian; een tool mag beide schrijven. Een ouder bestand met eigenschapsvoorwaarden op dossierniveau blijft werken — Plainva verdeelt ze de volgende keer dat het wordt opgeslagen over elke weergave.

Eigenschapsvoorwaarden gebruiken bare eigenschapsnamen en deze operatoren:

Structuur (eenwortelig!): een van and / or / not, waarvan de items voorwaarde-strings zijn — of één niveau van geneste {and:[...]} / {or:[...]}-groepobjecten (Notion-stijl groepen). Voorbeeld met een bron, een voorwaarde en een OF-groep:

filters:
  and:
    - 'file.folder == "Projects"'
    - 'status != "Done"'
    - or:
        - 'priority == "1"'
        - 'priority == "2"'

Een volledige, geannoteerde .base

filters:
  and:
    - 'file.folder == "Projects"'          # source: notes in the Projects folder
properties:
  note.status:                             # column id is note.-prefixed
    displayName: Status                    # optional Obsidian column label
    plainva:
      input: status
      options:
        - value: Open
          color: amber
          group: Active
        - value: Done
          color: green
          group: Closed
views:
  - type: table                            # first view: also carries file-wide keys
    name: All projects                     # every view needs a name
    order: [file.name, note.status]        # order uses note.-prefixed ids
    plainva:
      fileIconColor: "#2f6f6f"
      newItemFolder: Projects
  - type: table                            # a board is a native table + render hint
    name: Board
    plainva:
      render: board
      groupBy: status                      # groupBy uses the BARE key

Relaties (het tweezijdige contract)

Een relatie koppelt notities aan elkaar. Dit is het meest foutgevoelige om met de hand te schrijven, omdat het zich over drie plekken uitstrekt. Zorg dat alle drie consistent zijn.

1. De waarde staat in de frontmatter van de bronnotitie, als wiki-link (of een lijst daarvan):

   ---
   type: Task
   project: "[[Project Alpha]]"
   ---

2. De bron-.base declareert de relatiekolom (relationBase = de doeldatabase; relationLimit: one voor een enkele link):

   properties:
     note.project:
       plainva:
         input: relation
         relationBase: Projects.base
         relationLimit: one

3. De doel-.base kan de omgekeerde richting tonen met een berekende kolom. De waarden ervan worden nergens opgeslagen — ze worden afgeleid uit de links van de bronnotities:

   properties:
     note.tasks:
       plainva:
         reverseOf:
           base: Tasks.base       # the source .base (vault-relative path)
           property: project      # the BARE source property key

Uitgewerkt voorbeeld: Taken ↔ Projecten

Tasks.base

filters:
  and:
    - 'file.folder == "Tasks"'
properties:
  note.status:
    plainva:
      input: status
      options:
        - value: Open
          color: amber
        - value: Done
          color: green
  note.project:
    plainva:
      input: relation
      relationBase: Projects.base
      relationLimit: one
views:
  - type: table
    name: All tasks
    order: [file.name, note.status, note.project]

Projects.base

filters:
  and:
    - 'file.folder == "Projects"'
properties:
  note.tasks:
    plainva:
      reverseOf:
        base: Tasks.base
        property: project
views:
  - type: table
    name: All projects
    order: [file.name, note.tasks]

Tasks/Write proposal.md

---
type: Task
okf_version: "0.1"
status: Open
project: "[[Project Alpha]]"
---
# Write proposal

Projects/Project Alpha.md

---
type: Project
okf_version: "0.1"
---
# Project Alpha

Resultaat: in Projects.base toont de berekende tasks-kolom van Project Alpha “Write proposal”, omdat het project-veld van die taak ernaar terugverwijst. Merk op dat Project Alpha.md geen tasks:-sleutel heeft — de omgekeerde kant is berekend, nooit opgeslagen.

Relatie-DON’Ts

• Schrijf geen omgekeerde waarden in notities. Een reverseOf-kolom is berekend. Een tasks:-sleutel in Project Alpha.md schrijven is fout en overleeft geen roundtrip.
• Zorg dat linkdoelen resolven. "[[Project Alpha]]" moet overeenkomen met een bestaande notitienaam, anders toont de link als defect.
• Houd paden vault-relatief met schuine strepen en zonder voorloop-./ (Projects.base, DB/Projects.base).
• reverseOf.property is de bare bronsleutel (project), niet note.project.

Zelf-relaties en subitems

Voor een relatie waarvan het doel dezelfde database is, wijst relationBase naar diezelfde .base. Om kinderen onder ouders in een tabelweergave te nesten, zet je views[i].plainva.subItemsProperty op de bare bovenliggende-relatiesleutel. Cycli worden afgehandeld; met subitems uit blijven de rijen plat en de waarden behouden.

index.md (map-inhoudsopgave)

index.md is een gereserveerde naam voor het inhoudsoverzicht van een map.

• Alleen de root-index.md mag frontmatter dragen, en alleen okf_version (het markeert de vault als OKF-actief). Een niet-root-index.md moet frontmatter-vrij zijn — frontmatter daar is een schending van de gereserveerde naam.
• Een Plainva-beheerde index.md eindigt met de marker <!-- plainva:index generated --> (een HTML-commentaar, onzichtbaar in de leesmodus). De aanwezigheid ervan betekent dat Plainva het bestand automatisch actueel houdt. Bewerk je zo’n bestand met de hand, bewaar dan ofwel de marker (en houd de gegenereerde vorm aan) of verwijder hem bewust om het bestand permanent over te nemen.
• Gegenereerde listings zijn secties van links in de vorm * [Titel](relatief/url) - beschrijving.

Genereer je een mapoverzicht met de hand, dan is de veilige keuze om de marker niet toe te voegen — dan zal Plainva het nooit overschrijven.

Graaf-weergaven (plainva.render: "graph")

Een graaf-weergave wordt opgeslagen zoals elke niet-native weergave: type: table plus de render-hint. De opties ervan staan in DEZELFDE views[i].plainva-namespace:

views:
  - type: table
    name: Net
    plainva:
      render: graph
      graphEdges: [projekt]        # relation property keys drawn as edges
      graphColorBy: status         # select/status property -> node color
      graphSizeBy: prio            # number property -> node size
      graphShowExternal: true      # include relation targets outside the view
      graphShowIncoming: true      # relaties uit ANDERE databases die hiernaar verwijzen (bijv. de taken van een project)

Alle graaf-optiesleutels zijn optioneel; laat ze helemaal weg als ze niet zijn ingesteld. Obsidian rendert hetzelfde bestand als een gewone tabel en mag geen fout geven.

Een Bord-weergave (plainva.render: "board") kan daarnaast views[i].plainva.boardColumnOrder dragen — een lijst van groep-kolomsleutels (__UNGROUPED__ markeert de kolom zonder waarde) die een handmatige kolomvolgorde onthoudt. Selectie-/Status-borden ordenen in plaats daarvan de options van de eigenschap opnieuw. Weglaten als niet ingesteld.

De prikbordweergave (plainva.render: "pinboard")

Een prikbord wordt opgeslagen zoals elke niet-native weergave: type: table plus de render-hint. De sleutels ervan staan in dezelfde views[i].plainva-namespace:

views:
  - type: table
    name: Pinboard
    plainva:
      render: pinboard
      pinboardOrder:                  # handmatige volgorde van de niet-vastgezette kaarten
        - "Notes/Groceries.md"
      pinboardPinned:                 # vastgezet; lijstvolgorde = sectievolgorde
        - "Notes/Idea.md"
      pinboardFilterBy: note.labels   # labelbron van de chipbalk; weglaten = tags

Regels: vastgezette paden worden niet herhaald in pinboardOrder. Kaarten die in geen van beide lijsten staan, renderen bovenaan, nieuwste eerst (aanmaaktijd). Items waarvan het bestand niet meer bestaat of de bronset heeft verlaten, worden genegeerd en bij de volgende keer opslaan opgeruimd. Wanneer een notitie wordt hernoemd of verplaatst, werkt Plainva de paden in beide lijsten automatisch bij; externe tools moeten hetzelfde doen. Obsidian negeert de sleutels en toont de weergave als een tabel.

Niet-aanraken en veiligheid

• .plainva/ bevat back-ups en interne status. Lees er nooit programmalogica uit en schrijf er nooit naar.
• Onbekende sleutels zijn heilig. Als je een .base of een notitie herschrijft, draag dan elke sleutel mee die je niet van plan was te wijzigen. Plainva zelf bewaart onbekende .base-sleutels via een interne rauwe kopie; een externe schrijver zou hetzelfde moeten doen (parsen → alleen wijzigen wat je bedoelt → serialiseren).
• Waarden veranderen in de notitie, niet in de .base. Om een cel te zetten, bewerk je de frontmatter van de notitie. De .base bepaalt alleen welke notities en kolommen worden getoond.
• Voeg geen top-level .base-sleutels toe boven filters / formulas / properties / views.
• Encoding: UTF-8 zonder BOM, LF-regeleinden, overal.

Zie ook

• Notities & Markdown — hetzelfde materiaal vanuit de hoek van handmatig schrijven in de app
• Databases (.base) — databases uitgelegd voor alledaags gebruik
• OKF — type, okf_version, index.md en de vault-conversie