Bestandsformaat-referentie

Laatst bijgewerkt: 2026-10-22

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 vijf top-level sleutels (filters, formulas, properties, summaries, views). Obsidian begrijpt geen enkele andere top-level sleutel. Daarom staat alle Plainva-specifieke data 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. Een nieuw bestand krijgt LF-regeleinden en geen BOM; een bestand dat er al is, houdt wat het heeft. Plainva doet hetzelfde: wat het aanmaakt, begint met LF en zonder BOM, en wat het aantreft, houdt zijn regeleinden en zijn BOM — bewerk je een notitie, dan veranderen alleen de regels die je hebt gewijzigd. Een bestand dat beide soorten regeleinden mengt, krijgt bij de eerste bewerking overal de soort die de meeste regels hebben. Een regeleinde dat alleen uit een wagenterugloop (CR) bestaat — wat oude Mac-bestanden hebben — wordt gelezen, maar niet bewaard: de eerste keer dat zo’n bestand wordt gewijzigd, slaat Plainva het op met LF (met CRLF als de meeste andere regeleinden CRLF zijn) en meldt je dat.

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
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

Een blok mag leeg zijn: --- direct gevolgd door --- is een blok zonder eigenschappen, niet twee scheidingslijnen — de tekst van de notitie begint op de regel erna. Plainva laat geen leeg blok achter: wordt de laatste eigenschap verwijderd, dan verdwijnen de twee ----regels mee. Ze blijven alleen staan als de tekst zelf met een ----regel begint, die anders als het begin van een blok zou worden gelezen.

Een blok dat Plainva niet als eigenschappen kan lezen, blijft precies zoals het is: tekst tussen de twee ----regels die geen YAML is, of YAML dat een lijst is in plaats van sleutel: waarde-regels. Eigenschappen meldt dat in plaats van geen eigenschappen te tonen, en wijzig je bij zo’n notitie een eigenschap — daar, in een database, op een prikbord, in de takenlijst, of het pictogram en de kleur ervan —, dan verandert er niets, en Plainva meldt dat: Eigenschap kon niet worden opgeslagen, gevolgd door de reden. Corrigeer het blok in de tekst van de notitie, dan lukt de wijziging. Eén waarde in een onverwachte vorm maakt een blok niet onleesbaar: Plainva leest haar zoals ze er staat — een lege tags: is een notitie zonder tags, een getal tussen de tags (- 2024) is de tag 2024, een getal als title is die titel, en een timestamp die een datum is, is een eigenschap als elke andere.

OKF-frontmattervelden

Plainva volgt OKF (Open Knowledge Format), een minimale conventie — momenteel versie 0.2. Eén top-level veld is verplicht, de rest is optioneel:

Een bestand zonder type opent nog steeds prima; het is alleen “niet OKF-conform”. Een okf_version die in een notitie ontbreekt — of er nog steeds in staat — is geen overtreding. Als je een nieuwe notitie aanmaakt, is het goede praktijk om type toe te voegen — meer is niet nodig. Zie OKF voor de volledige onderbouwing.

Vertrouwen en levenscyclus (OKF 0.2)

OKF 0.2 voegt vijf optionele top-level velden toe waarmee een notitie kan zeggen waar ze vandaan komt, of iemand haar heeft gecontroleerd, en of ze nog geldig is. Plainva leest ze allemaal; het schrijft ze volgens vaste regels (zie hieronder).

Actoren (by in generated en verified) volgen een conventie: een persoon is human:<naam>, een programma is <producent>/<versie>. Plainva schrijft plainva-import/<versie>, plainva-mail-capture/<versie> en plainva-task-sync/<versie> — en, bij een controle, human:<jouw naam>.

Voorbeeld van een geïmporteerde, later gecontroleerde notitie:

---
type: Note
generated:
  by: plainva-import/0.6.7
  at: 2026-08-21T10:11:12Z
sources:
  - resource: https://example.org/article
    title: Article
verified:
  - by: human:Marco
    at: 2026-08-22T08:00:00Z
status: stable
stale_after: 2027-08-21
---

Schrijfregels — wie zet wat:

• generated en sources worden alleen geschreven door Plainva’s machinale schrijfpaden: de import (één moment per run; het importrapport draagt het ook), e-mail vastleggen (met sources: [{ resource: "mid:<Message-ID>" }] wanneer het bericht een stabiel Message-ID heeft) en de takensynchronisatie (alleen wanneer die een notitie aanmaakt — een latere synchronisatie laat de stempel met rust).
• verified wordt alleen geschreven door Markeren als gecontroleerd (desktop: de sectie Vertrouwen en herkomst van het eigenschappenpaneel; telefoon: de contextkaart van de notitie) — en dat voegt toe in plaats van te overschrijven.
• De editor raakt geen van deze velden ooit uit zichzelf aan, en bestaande notities krijgen nooit achteraf een stempel. Een ontbrekend veld betekent alleen: geen uitspraak.
• status en stale_after stel je zelf in (als eigenschap of rechtstreeks in de frontmatter). Een waarde buiten draft/stable/deprecated — zeg de status: Open-kolom van een takendatabase — is geen levenscyclusstatus maar een gewone eigenschap; Plainva toont er geen badge voor.
• Tools en scripts die notities aanmaken, zetten generated met hun eigen actor (<jouw-tool>/<versie>) en laten vertrouwensvelden die ze niet kennen ongewijzigd door een lees-/schrijfronde gaan.

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 waar het vandaan komt, en afhankelijk van het soort calendar (vergadernotities), kind: task + list (gesynchroniseerde taken) of kind: email + mailbox (vastgelegde e-mails). Tools moeten hem ongewijzigd bewaren; het anker verwijderen ontkoppelt de notitie alleen van het externe object (er wordt extern niets verwijderd). Voorbeeld:

plainva:
  pim:
    kind: task
    uid: MTIzNDU2
    list: MDEyMzQ1
    provider: caldav
    identity: https://cloud.example.com:alice
    account: 3f9c21ab

Wat de herkomst beschrijft. Voor een taak tellen uid en list — een uid is uniek bij ÉÉN provider, niet over twee heen. provider (google, microsoft, caldav) en identity (de geverifieerde account-identiteit, waar de provider die aanbiedt) bakenen het verder af, en beide overleven een herverbinding. account is de LOKALE account-id: Plainva schrijft hem nog steeds zodat oudere versies het anker kunnen lezen, maar vergelijkt hem niet meer — hij wordt bij elke verbinding opnieuw geslagen, en dat is precies waarom een opnieuw verbonden account zijn taken vroeger een tweede keer importeerde. Schrijf je zelf ankers, zet dan uid en list; provider/identity worden aanbevolen, account is niet nodig. recurring: true voegt Plainva aan een taakanker toe zodra het heeft gezien dat de aanbieder de taak laat terugkomen (afgerond, daarna onder dezelfde uid weer open met een latere datum). De sleutel is puur informatief, wordt nooit vergeleken en mag worden verwijderd.

De bestandsnaam hoort niet bij de identiteit. Een gespiegelde taak heet zoals haar titel (<titel>.md, bij dezelfde titel <titel> 2.md enzovoort); gekoppeld wordt uitsluitend via het anker. Tools mogen het bestand hernoemen en verplaatsen zolang het anker blijft. Namen van de vorm <titel> — <16 of 64 hextekens>.md stammen uit de Plainva-versies van 12 tot 24 september 2026: de tekens zijn het begin van een SHA-256 over aanbieder, identiteit, lijst en uid. De takenweergave biedt eenmalig aan ze naar hun titel te hernoemen — alleen als de tekens bij het anker in hetzelfde bestand passen.

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]] — een klik opent de notitie bij die kop; [[#Sectie]] springt binnen de huidige notitie, en een slug in GitHub-stijl ([[Notitie#cool-header]]) wordt ook opgelost. Met een blokverwijzing: [[Notitie#^id]] voor een regel die eindigt op ^id. Met weergavetekst: [[Notitie|getoonde tekst]].
• Hoe het doel van een wiki-link wordt opgelost — hetzelfde voor een klik, een insluiting, een relatie, de graaf en de backlinks, op de desktop en op de telefoon. In deze volgorde: (1) een expliciet pad — /Map/Notitie vanaf de vault-root, ./Notitie of ../Map/Notitie vanaf de map van de notitie met de link — en voor zo’n doel niets anders; (2) het vaultpad zoals geschreven — een bestand dat precies zo gespeld is —, daarna de notitie op dat pad (.md); (3) het einde van het pad van een notitie: de bestandsnaam alleen of met mappen ervoor (Klanten/Brief vindt Projecten/Klanten/Brief.md); (4) een bestand dat geen notitie is (plan.pdf, Tasks.base, LICENSE), via zijn pad of het einde van zijn pad — na de notities, dus een doel zonder extensie is een notitie waar er een bestaat; (5) de title uit de eigenschappen van een notitie. Namen worden vergeleken zonder onderscheid tussen hoofdletters en kleine letters, en de samengestelde en de ontlede schrijfwijze van een letter gelden als dezelfde naam. Passen er meerdere bestanden: eerst de schrijfwijze zoals geschreven, dan het pad gelezen vanaf de map van de notitie met de link (bij een kale naam de notitie ernaast), dan het kortste pad, dan de alfabetische volgorde. De stappen 1 tot en met 4 zijn ook de manier waarop Obsidian een bestand vindt, al kan het een ander kiezen wanneer meerdere dezelfde naam hebben; een link via title (stap 5) werkt alleen in Plainva — daarom schrijven de keuzelijsten van Plainva de bestandsnaam.
• Markdown-link: [tekst](doel). Het doel wordt eerst gelezen vanaf de map van de notitie met de link — het bestand dat precies zo gespeld is, daarna de notitie op dat pad (.md); ligt daar niets, dan wordt het opgelost als het doel van een wiki-link (stappen 2 tot en met 5 hierboven: het pad vanaf de vault-root, het einde van een pad, een bestand dat geen notitie is, de title). Een expliciet pad — /Map/Bestand, ./Bestand, ../Map/Bestand — noemt één plek, en er wordt niets anders voor geprobeerd. Een doel dat op / eindigt, noemt een map en leidt naar de index.md daarvan. De procentcodering wordt gedecodeerd (Mijn%20brief.md), punthaken en een titel worden gelezen zoals in CommonMark ([x](<Mijn brief.md> "Titel")), en de eerste # die er staat begint een fragment: met [tekst](#cool-header) of [tekst](andere.md#cool-header) landt de klik op de kop; een # die bij een bestandsnaam hoort, wordt als %23 geschreven. Links in elk van de drie formaten van Obsidian — kortste pad, relatief pad, absoluut pad in de vault — worden zo opgelost; ligt er één bestand op het pad vanaf de map van de notitie met de link en een ander op hetzelfde pad vanaf de vault-root, dan neemt Plainva het eerste, zoals een Markdown-lezer buiten de app dat doet. Plainva zelf schrijft relatieve Markdown-links met procentcodering (mapoverzichten, voorbereide overzichten). Het antwoord is hetzelfde voor een klik, de graaf en de backlinks, op de desktop en op de telefoon.
• Backlinks worden automatisch afgeleid, ook uit frontmatter-wiki-links (dat is wat relaties als backlinks laat verschijnen).

Afhankelijkheden (blockedBy)

Een gewone notitie-eigenschap — buiten de plainva:-naamruimte — volgens RFC 9253, het vocabulaire dat ook de TaskNotes-plug-in schrijft:

blockedBy:
  - uid: "[[Projects/Rollout]]"   # wikilink naar de voorganger
    reltype: FINISHTOSTART        # vocabulaire uit RFC 9253
    gap: P1D                      # optionele vertraging, ISO 8601

• Sla maar één richting op (de opvolger noemt zijn voorgangers). De omgekeerde wordt afgeleid; een opgeslagen paar zijn twee feiten die elkaar kunnen tegenspreken.
• reltype mag FINISHTOSTART, FINISHTOFINISH, STARTTOSTART of STARTTOFINISH zijn. Plainva evalueert en tekent alleen FINISHTOSTART; de rest blijft onaangeroerd behouden.
• gap is een ISO-8601-duur en optioneel.
• Schrijf geen cyclus. Plainva weigert er een en noemt het pad dat hij zou sluiten.

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.

taskList geeft de taaklijst aan waarin een in Plainva aangemaakte taak ook bij de provider wordt aangemaakt (Google Tasks, iCloud-herinneringen, Microsoft). De waarde is de account-id en de lijst-id gescheiden door de eerste spatie — een CalDAV-lijst-id kan zelf spaties bevatten. Zonder de sleutel blijft een nieuwe taak een gewone notitie. Als de waarde niet meer oplosbaar is (account verwijderd, lijst verwijderd), gedraagt Plainva zich alsof de sleutel ontbreekt, in plaats van een andere lijst te gokken. Obsidian negeert de sleutel.

Invoertypen

plainva.input is een van:

text  number  rating  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. Een rating-kolom houdt in het bestand een gewoon getal — stemming: 4 — en wordt als punten getekend. Twee optionele subsleutels sturen dat:

    note.stemming:
      plainva:
        input: rating
        ratingMax: 5        # 1 tot 10, standaard 5
        ratingGlyph: "★"      # één teken, standaard een punt

Sorteren en filteren gaan als bij number. Obsidian kent rating niet en toont de kolom als een getal — wat ze is.

file.day is een virtueel veld: de dag waar de bestandsnaam van een dagnotitie voor staat, volgens map en formaat van de kluis. Het staat in geen enkele notitie, wordt bij het bevragen berekend en is alleen-lezen; de enige plek waar het dienst doet is het dateField van een agenda- of tijdlijnweergave. Obsidian kent het niet — een weergave die het gebruikt blijft daar leeg.

Aggregatie

Een aggregatie-kolom heeft ook geen input. Ze berekent een waarde uit de notities waar een linkkolom van DEZE database naar verwijst:

properties:
  note.offen:
    displayName: Open
    plainva:
      rollup:
        through: aufgaben      # een relatie- OF omgekeerde kolom van deze database
        of: status             # een eigenschap van de gekoppelde notities
        fn: countWhere
        where:
          op: "!="             # ==  !=  contains  notContains  >  <  >=  <=
          value: Erledigt

• fn is een van: count, countWhere, percentWhere, sum, average, median, min, max, earliest, latest, checked, unchecked, empty, filled, unique.
• of wordt alleen weggelaten bij count. where is alleen toegestaan bij countWhere en percentWhere, waar het verplicht is.
• Een lege operand (value: "") is de is-leeg-operator, precies zoals bij de filters.
• De waarde staat in geen enkel bestand. Schrijf ze nooit naar de frontmatter — ze wordt bij elke query opnieuw berekend, en een geschreven waarde zou vanaf de eerste wijziging fout zijn.
• Een onvolledige of onbekende aggregatie wordt bij het lezen weggelaten in plaats van als fout behandeld: de kolom blijft leeg, het bestand opent.
• Obsidian kent de sleutel niet en toont de kolom leeg. Het bestand blijft geldig.

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
status: Open
project: "[[Project Alpha]]"
---
# Write proposal

Projects/Project Alpha.md

---
type: Project
---
# 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 — de conventieversie die de vault volgt (momenteel "0.2"; het markeert de vault als OKF-actief). Een vault die nog "0.1" declareert, wordt getild onder Instellingen → Vault → Inhoud en structuur → Bundleversie → Bijwerken…; het verouderde okf_version-veld kan in dezelfde stap uit de notities worden verwijderd. 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. Nieuwe bestanden: LF-regeleinden, geen BOM. Een notitie of tekstbestand dat al CRLF-regeleinden of een BOM heeft, houdt die — Plainva verandert ze niet, en een tool hoort dat ook niet te doen. De enige uitzondering is een .base: Plainva schrijft die opnieuw, met LF en zonder BOM, zodra de configuratie verandert. Een regeleinde dat alleen uit een wagenterugloop (CR) bestaat (oude Mac-bestanden), wordt gelezen, maar niet bewaard: Plainva slaat zo’n bestand met LF op zodra het dat bestand voor het eerst wijzigt.

Zie ook

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

Kleurstrook / Pictogram / Tags · hele notitie

Filter op kleurstrook, pictogram, tags van de hele notitie of de labeleigenschap van de prikbordweergave. Tags komen exact overeen: #work vindt niet #workshop of #work/child. Tekst en frontmatter worden samengevoegd. Waarden blijven uit de hele bron beschikbaar, ook zonder resultaten; onbekende pictogramnamen blijven bewaard.

filters:
  and:
    - file.folder == "Notes"
views:
  - type: table
    name: Example
    filters:
      and:
        - 'note.plainva.header_color == "#2a7f7b"'
        - 'note.plainva.icon == "lucide:pin"'
        - 'file.tags.contains("#work")'

• bevat niet: !file.tags.contains("#work")
• is leeg: file.tags.isEmpty()
• is niet leeg: !file.tags.isEmpty()

Taakeigenschappen: tijd, prioriteit, herinnering, statussen

• Vervaltijdstip. De vervaleigenschap van een taak — de datumkolom van de database, vervaldatum in een Nederlandse vault — kan een tijdstip dragen: vervaldatum: 2026-09-21T14:00. Plainva leest het tijdstip ongeacht het type van de kolom; een kale dag (2026-09-21) en middernacht (T00:00) betekenen beide ‘geen tijdstip’. Een door Plainva aangemaakte takendatabase typeert de kolom als datum & tijd; een oudere behoudt zijn gewone datumkolom totdat je het eenmalige aanbod om over te schakelen accepteert. Naar Google, Microsoft en CalDAV reist een taak nog altijd met alleen zijn dag.
• Prioriteit. Een keuzekolom waarvan de naam in een van Plainva’s tien talen ‘prioriteit’ betekent (priority, priorität, prioridad, priorité, priorità, 優先度, prioriteit, priorytet, prioridade, 优先级). De rang is de positie van de optie: eerste = hoog, tweede = gemiddeld, derde = laag; leeg = geen. De bewoording van de opties bepaal je zelf.
• Uitzondering op de herinnering. remind: off schakelt de herinnering van één taak uit; remind: 30 herinnert 30 minuten voor het tijdstip (alleen zinvol bij een taak met een tijdstip). Zonder deze eigenschap gelden de instellingen.
• Statussen van selectievakjes. - [ ] open, - [x] klaar, - [/] bezig, - [-] geannuleerd. Bezig telt als open, geannuleerd als afgerond; een geannuleerde subtaak verlaat de telling file.tasks. Plainva schrijft [/] en [-] alleen wanneer je Status instellen kiest.
• Prioriteitstekens op een selectievakje. Gelezen: 🔺 ⏫ (hoog), 🔼 (gemiddeld), 🔽 ⏬ (laag). Geschreven: ⏫, 🔼 of 🔽, geplaatst voor het eerste datumveld.

Journaalitems

• Waar. Onder een kop van de dagnotitie waarvan de tekst de journaalkop van de vault is (instelling Kop van het journaal, standaard Journal); het niveau van de kop (# tot ######) maakt niet uit. De sectie eindigt bij de volgende kop van het hoogste niveau van de notitie. Regels binnen codeblokken en HTML-commentaar zijn geen items.
• Geschreven vorm. - HH:mm Tekst — 24-uurs lokale tijd van het apparaat, één spatie, dan de tekst. Verdere regels van hetzelfde item zijn vervolgregels, ingesprongen tot de tekst. Een taakitem draagt het selectievakje vóór het tijdstip: - [ ] HH:mm Tekst.
• Ook gelezen. HH:mm:ss, een enkelcijferig uur (9:05), de opsommingstekens * en +, elke status van een selectievakje ([ ], [x], [/], [-]), en lijsten met lege regels tussen de items. Een lijstregel zonder tijdstip is geen item en blijft onaangeroerd.
• Volgorde. Nieuwe items worden aan het einde van de sectie toegevoegd, vóór afsluitende lege regels; de lijst behoudt het opsommingsteken en de spatiëring die de notitie al gebruikt. Een ontbrekende kop wordt met de ingestelde tekst als ## Journal aan het einde van de notitie toegevoegd, met één lege regel ertussen. Geen enkele bestaande regel wordt opnieuw opgemaakt; regeleindes (LF of CRLF) en de frontmatter blijven zoals ze zijn.
• Samenvoegen. Hebben twee apparaten aan dezelfde sectie toegevoegd, dan verenigt de synchronisatie de items op tijdstip — hele items, nooit losse regels; identieke regels eenmaal, bij een gelijk tijdstip de lokale eerst. Dat geldt ook wanneer beide apparaten de notitie hebben aangemaakt. Elk ander verschil is een conflict zoals voorheen.
• Instelling. journalHeading maakt deel uit van het instellingenprofiel van de vault, naast de map en het formaat van de dagnotitie, zodat elk apparaat dezelfde kop leest.