Bestandsformaat-referentie

Laatst bijgewerkt: 2026-09-10

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

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]].
• Markdown-link: [tekst](relatief/pad.md) werkt ook. Met een fragment ([tekst](#cool-header), [tekst](andere.md#cool-header)) landt de klik op de kop.
• 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  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.

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 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, de bundleversie, de vertrouwensvelden van OKF 0.2, index.md en de vault-conversie