ファイル形式リファレンス

最終更新: 2026-09-10

このページは、Plainva保管庫内のすべてのファイルについて、ディスク上での正確な形式契約を示します。ツール——他のプログラム、スクリプト、あるいはAIアシスタント——がPlainvaのユーザーインターフェースを経由せずに保管庫のファイルを直接読み書きできるように書かれています。アプリだけを使うなら、このページは不要です。通常の使い方は他のガイドページで説明しています。

ここに書かれているものはすべて純粋なUTF-8テキストです。ノートはYAMLフロントマター付きのMarkdownで、データベースはYAMLです。独自仕様のものは何もなく、隠されたものもありません。

黄金律（まず読むこと）

1. ノートが真実の源です。.baseは単なるビューにすぎません。 プロパティの値は個々のノートのフロントマターに存在し——.baseの中には決して存在しません。値を変更するには、ノートを編集してください。
2. ノートはObsidianネイティブのままです。 ノートのフロントマターには、常に単純なスカラーとリストのみを書いてください（文字列、数値、真偽値、ISO日付、YAMLリスト）。入れ子になったオブジェクトや「アクティブ/選択中」フラグをノートに書き込むことは絶対にありません。
3. .baseはObsidianの5つのトップレベルキーだけを使います（filters、formulas、properties、summaries、views）。Obsidianはそれ以外のトップレベルキーを理解しません。だからこそ、Plainva固有のデータはすべて入れ子のplainva:サブキーの下に置かれます。
4. 理解できないものは保持してください。 未知のキーは、読み書きの往復を経ても変わらず生き残らなければなりません。認識できないキーを「整理」しないでください。
5. BOMなしのUTF-8で、LF改行で書いてください。

保管庫の全体像

保管庫は普通のフォルダーです。あなたが出会うファイルタイプ:

予約名index.mdとlog.mdは決して通常のノートではありません。これらの名前で通常のコンテンツを作成しないでください。

ノート (.md)

ノートはMarkdownファイルです。任意のYAMLフロントマターブロック（2つの---行の間）が一番上にあり、プロパティを保持します。その後にMarkdown本文が続きます。

---
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フロントマターフィールド

Plainvaは最小限の規約であるOKF（Open Knowledge Format）に従います——現在はバージョン0.2です。トップレベルフィールドは1つだけ必須で、その他はすべて任意です:

typeがないファイルも問題なく開きます。単に「OKF非準拠」であるというだけです。okf_versionが欠けているだけでは違反にはなりません。新規ノートを作成する際は、typeを追加するのがよい習慣です——それ以上は何も必要ありません。完全な根拠はOKFを参照してください。

信頼とライフサイクル（OKF 0.2）

OKF 0.2は、ノートが自分がどこから来たのか、誰かがレビューしたのか、まだ有効なのかを示す5つの任意のトップレベルフィールドを追加します。Plainvaはそれらすべてを読み取り、決まったルールに従って書き込みます（下記参照）。

アクター（generatedとverifiedのby）は規約に従います: 人はhuman:<name>、プログラムは<producer>/<version>です。Plainvaはplainva-import/<version>、plainva-mail-capture/<version>、plainva-task-sync/<version>を書き込みます——そしてレビューの場合はhuman:<あなたの名前>です。

インポートされ、その後レビューされたノートの例:

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

書き込みルール——誰が何を設定するか:

• generatedとsourcesは、Plainvaの機械による書き込み経路によってのみ書き込まれます: インポーター（実行ごとに1つの時刻——インポートレポートにも記録されます）、メール取り込み（メッセージに安定したMessage-IDがある場合はsources: [{ resource: "mid:<Message-ID>" }]とともに）、タスク同期（ノートを新規作成するときのみ——それ以降の同期はスタンプに触れません）。
• verifiedは確認済みにする（デスクトップ: プロパティパネルの信頼性と出所セクション、スマートフォン: ノートのコンテキストシート）によってのみ書き込まれ、上書きではなく追記されます。
• エディターはこれらのフィールドを自ら触れることはなく、既存のノートが後から書き換えられることもありません。フィールドがないことは、単に「何も述べていない」ことを意味するだけです。
• statusとstale_afterはプロパティとして、あるいはフロントマターに直接、自分で設定するものです。draft/stable/deprecated以外の値——例えばタスクデータベースのstatus: Open列——はライフサイクルの状態ではなく、通常のプロパティです。Plainvaはそれに帯表示を付けません。
• ノートを作成するツールやスクリプトは、自分自身のアクター（<your-tool>/<version>）でgeneratedを設定し、知らない信頼フィールドはそのまま往復させるべきです。

プロパティ値のシリアライズ

各フロントマターキーは1つのプロパティです。値はその型のネイティブなYAML形式で書いてください。

選択/ステータスプロパティの「アクティブな」値は、単なるこのプレーンなスカラーです。許可されたオプションのパレットとその色は、ノートには存在せず——それらを支配する.baseに存在します（オプションと色を参照）。これにより、ノートは100%Obsidianネイティブに保たれます。

Wikiリンクの値は引用符で囲んでください（"[[X]]"）。引用符のない[[X]]はYAMLのフローシーケンスとなり、意図したようにはパースされません。

ノート内のplainva:ネームスペース

Plainva固有のノート拡張情報は、他のエディターが無視できるよう単一のplainva:キーの下にまとめられています。

これらはすべて任意です。どれも書かない場合は、plainva:キー自体を省略してください。無効な値は読み込み時に無視され、エラーとしては扱われません。

pimはPIM統合のアンカーです（カレンダーと外部タスクとメールの取り込みを参照）。これは、ノートが外部のオブジェクトをミラーするときにPlainvaが書き込む小さなマッピングです: uidとその由来に加えて、種類に応じてcalendar（会議ノート）、kind: task + list（同期されたタスク）、またはkind: email + mailbox（取り込んだメール）が入ります。ツールはこれを変更せずに保持すべきです。アンカーを削除しても、そのノートをリモートのオブジェクトから切り離すだけです（それによってリモート側で何かが削除されることはありません）。例:

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

由来を表すもの。 タスクの場合、重要なのはuidとlistです——uidは1つのプロバイダー内で一意であり、2つにまたがって一意ではありません。provider（google、microsoft、caldav）とidentity（検証済みのアカウントID、プロバイダーが提供している場合）は、それをさらに絞り込む役割を持ち、どちらも再接続を乗り越えます。accountはローカルのアカウントIDです: Plainvaは古いバージョンがこのアンカーを読めるように、これをそのまま書き込みますが、もはや比較には使いません——これは接続のたびに新しく生成されるものであり、まさにそれこそが、再接続したアカウントが以前タスクを二重にインポートしてしまっていた理由です。自分でアンカーを書く場合は、uidとlistを設定してください。provider/identityは設定を推奨しますが、accountは不要です。

templateForはテンプレート割り当てのフィールド契約です（データベース (.base)を参照）。テンプレートフォルダー内のノートでは、そのテンプレートをデフォルトでエントリーメニューに表示するデータベースを一覧します。値は.base拡張子を含む完全なWikiリンクです——bare形式（"[[Tasks.base]]"はどのフォルダーにあってもその名前のファイルにマッチするため、単純なフォルダー移動を乗り越えます）か、パス修飾形式（"[[Projekte/Tasks.base]]"はそのパスに完全一致する場合のみマッチします）のいずれかです。Plainvaはbareなリンクを書き込み、同名の.baseファイルが2つ存在する場合にのみパスで修飾します。リストの代わりにスカラーを指定することも許容されます。エントリをテンプレートから作成する際、templateForは——他のplainva:キーとは異なり——新しいノートにはコピーされません。

リンク

• Wikiリンク: [[ノート名]] — 保管庫全体でノート名によって解決されます。見出しアンカー付き: [[ノート#セクション]] — クリックするとノートがその見出しの位置で開きます。[[#セクション]] は現在のノート内で移動し、GitHub 形式のスラッグ（[[ノート#cool-header]]）も解決されます。ブロック参照: [[ノート#^id]] は ^id で終わる行を指します。表示テキスト付き: [[ノート|表示テキスト]]。
• Markdownリンク: [テキスト](相対/パス.md)も動作します。 フラグメント付き（[テキスト](#cool-header)、[テキスト](other.md#cool-header)）ならクリックで見出しに移動します。
• バックリンクはフロントマターのWikiリンクからも含め、自動的に導出されます（これによりリレーションがバックリンクとして表示されます）。

依存関係（blockedBy）

plainva: 名前空間の外にある通常のノートプロパティで、RFC 9253（TaskNotes プラグインも書き込む語彙）に従います。

blockedBy:
  - uid: "[[Projects/Rollout]]"   # 先行タスクへのウィキリンク
    reltype: FINISHTOSTART        # RFC 9253 の語彙
    gap: P1D                      # 任意の間隔（ISO 8601）

• 保存するのは片方向だけです（後続タスクが先行タスクを挙げます）。逆方向は導出されます。両方を保存すれば、互いに食い違いうる二つの事実になります。
• reltype には FINISHTOSTART、FINISHTOFINISH、STARTTOSTART、STARTTOFINISH を指定できます。Plainva が評価して描画するのは FINISHTOSTART のみで、他はそのまま保持されます。
• gap は ISO-8601 の期間で、省略できます。
• 循環は書かないでください。Plainva はこれを拒否し、閉じてしまう経路を示します。

データベース (.base)

.baseファイルはYAMLです。ノートに対するビュー——どのノート（ソース）、どう表示するか（ビュー）、どうフィルター・ソートするか、そして列スキーマ——を保存します。ノートの値は一切保存しません。 この形式はObsidianのBasesプラグインと互換性があります。

破ってはいけないルール——1つでも破るとObsidianはファイル全体を拒否します

• これらのトップレベルキーのみ: filters、formulas、properties、views。他のトップレベルキーは絶対に追加しないでください（歴史的に、トップレベルのcolumns:キーはすべてのファイルを壊しました——このパターンを復活させないでください）。
• すべてのビューは空でない文字列のnameを必要とします。
• filtersオブジェクトは各レベルでand / or / notのうち正確に1つだけを持ちます — 決して2つを並べて持ちません。

Plainva自身は、最後の2つのルールに違反する古いファイルを次に保存するときに修復しますが、直接書き込むツールは最初から正しくしなければなりません。

プロパティ識別子: note.接頭辞をいつ使うか

これはつまずきやすいポイントなので、明示しておきます。

経験則: Obsidian向けの構造フィールドはnote.<key>を使い（そしてfile.name、file.folder、file.mtimeのような組み込みにはfile.<x>を使い）、フィルター式または**plainvaブロック**の中はすべて、ありのままのフロントマターキーを使います。

トップレベルキー

• filters — このデータベースに属するノート。Plainvaでは、これはソース（フォルダー/タグ）のみを保持し、プロパティのフィルター条件はビューごとにviews[i].filtersの下に保存されます。フィルターを参照。
• properties — プロパティIDをキーとする列スキーマ。displayName（列見出しラベル）のようなネイティブのObsidianサブキーは許可され、保持されます。Plainvaのリッチネスはすべてproperties[id].plainvaの下にあります。
• views — 順序付きのビューのリスト。それぞれnameとtypeが必要です。
• formulas — Obsidianの機能です。Plainvaはこれらを作成しませんが、変更せずに保持します。

plainva:サブキーマップ

Plainva固有のものはすべてネームスペース化されています。3つの場所があります。

properties[<note.key>].plainva — 列ごと:

views[i].plainva — ビューごと:

plainvaブロックとは別に、ビューはネイティブの**views[i].filters**オブジェクトを持つことができます——ビューごとのプロパティフィルターです（ファイルレベルのfiltersと同じ、単一ルートのand/or/not構造です）。Plainvaはプロパティのフィルタールールをここに、ビューごとに1セットずつ保存するため、各ビューは独立してフィルタリングされます。ファイルレベルのfiltersはソースのみを保持します。Obsidianはネイティブにviews[i].filtersをビューごとに適用します。

views[0].plainva — ファイル全体のキー、最初のビューのみで許可:

contextFiltersは、Notionの「this page」フィルターに相当するPlainvaの機能です。各エントリはプロパティキーであり、データベースがノートに埋め込まれると、その行はそのプロパティを通じてホストノートに絞り込まれます（リンクインデックスを介して解決されます——所有側/Wikiリンクのプロパティはホストを指す行にマッチし、計算された逆リレーション列はホストが指す先にマッチします）。これは意図的にネイティブのfiltersには書き込まれません——そのためObsidianはこれを無視し、すべての行を表示します。Plainvaで単独で開いた場合も、ホストが存在しないため同様に適用されず、すべての行が表示されます。複数のエントリはAND条件で結合されます。

taskListは、Plainvaで作成されたタスクが提供元のどのタスクリストにも作成されるかを示します（Google Tasks、iCloudのリマインダー、Microsoft）。値はアカウントidとリストidを最初のスペースで区切ったものです——CalDAVのリストid自体にスペースが含まれることがあるためです。このキーがなければ、新しいタスクは単なるノートのままです。値が解決できなくなった場合（アカウントが削除された、リストが削除された）、Plainvaは別のリストを推測するのではなく、キーが存在しないかのように振る舞います。Obsidianはこれを無視します。

入力タイプ

plainva.inputは次のいずれかです。

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

計算された逆列にはinputがありません——reverseOfによってのみ識別されます。

ロールアップ

ロールアップ列にもinputはありません。このデータベースのリンク列が指し示すノートから値を計算します：

properties:
  note.offen:
    displayName: Open
    plainva:
      rollup:
        through: aufgaben      # このデータベースのリレーション列または逆列
        of: status             # リンクされたノートのプロパティ
        fn: countWhere
        where:
          op: "!="             # ==  !=  contains  notContains  >  <  >=  <=
          value: Erledigt

• fnは次のいずれかです: count、countWhere、percentWhere、sum、average、median、min、max、earliest、latest、checked、unchecked、empty、filled、unique。
• ofが省略できるのはcountのときだけです。whereはcountWhereとpercentWhereでのみ使用でき、その場合は必須です。
• 空のオペランド（value: ""）は、フィルターと同様に「空である」演算子です。
• この値はどのファイルにも存在しません。 フロントマターに書き込まないでください——クエリのたびに再計算され、書き込んだ値は最初の変更以降ずっと誤ったものになります。
• 不完全または未知のロールアップは、エラーとして扱われるのではなく、読み込み時に破棄されます。列は空のままで、ファイルは開きます。
• Obsidianはこのキーを認識せず、列を空として表示します。ファイルは有効なままです。

オプションと色

選択/ステータス/複数選択列は、キュレーションされたオプションリストを持つことができます。各オプション:

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はCSSカラーではなくパレット名です。有効な名前: gray、teal、blue、green、amber、coral、purple、pink。未知の色は、値から導出された色にフォールバックします。

ビュータイプ

ディスク上のviews[i].typeはネイティブのObsidianタイプです。Plainva専用のレンダリングはtype: tableにplainva.renderヒントを加えて書き込まれるため、Obsidianはそれらを単純なテーブルに縮退させます。

フィルター

filtersは、どのノートがデータベースに含まれるかを選択し、それらを絞り込みます。

ソース条件がメンバーシップを決定します。

• フォルダー: file.folder == "Path/To/Folder"（保管庫相対、ルートフォルダーは""）。
• タグ: file.hasTag("project")（先頭の#なし）。

複数のソースは、単に複数のエントリです。filtersが全くない場合 = 保管庫内のすべてのノート。

プロパティ条件がどこに存在するか: ファイルレベルでは、filtersはすべてのビューに適用されます。Plainvaは代わりに、プロパティのフィルタールールをビューごとにviews[i].filters（同じ単一ルート構造）に保存し、ファイルレベルにはソースのみを保持するため、各ビューは独立してフィルタリングできます。どちらもObsidianにとって有効であり、ツールはどちらを書き込んでも構いません。ファイルレベルにプロパティ条件を持つ従来のファイルも引き続き動作します——Plainvaは次回の保存時に、それらを各ビューへ振り分けます。

プロパティ条件は、ありのままのプロパティ名と次の演算子を使います。

構造（単一ルート！）: and / or / notのいずれか1つで、そのエントリは条件文字列——または、1階層のネストされた{and:[...]} / {or:[...]}グループオブジェクト（Notion風のグループ）です。ソース、条件、ORグループを組み合わせた例:

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

完全な注釈付き.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

リレーション（両側の契約）

リレーションはノート同士を結びつけます。これは手で書く際に最もエラーが起きやすいものです。なぜなら3つの場所にまたがるからです。3つすべてを一貫させてください。

1. 値はソースノートのフロントマターに存在します、Wikiリンク（またはそのリスト）として:

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

2. ソースの.baseがリレーション列を宣言します（relationBase = 対象データベース、単一リンクの場合はrelationLimit: one）:

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

3. 対象の.baseは、計算列で逆方向を表示できます。 その値はどこにも保存されません——ソースノートのリンクから導出されます:

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

実例: タスク ↔ プロジェクト

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

結果: Projects.baseでは、Project Alphaの計算列tasksに「Write proposal」が表示されます。なぜなら、そのタスクのprojectがProject Alphaにリンクバックしているからです。Project Alpha.mdにはtasks:キーがないことに注目してください——逆側は計算されるものであり、決して保存されません。

リレーションでやってはいけないこと

• 逆方向の値をノートに書き込まないでください。 reverseOf列は計算されたものです。Project Alpha.mdにtasks:キーを書き込むのは誤りであり、往復（round-trip）を生き残りません。
• リンク先が解決するようにしてください。 "[[Project Alpha]]"は既存のノート名と一致しなければなりません。さもないとリンクは壊れて表示されます。
• パスは保管庫相対に保ってください、スラッシュを使い、先頭の./はなしで（Projects.base、DB/Projects.base）。
• reverseOf.propertyはbareなソースキーです（project）、note.projectではありません。

セルフリレーションとサブアイテム

対象が同じデータベースであるリレーションの場合、relationBaseはその同じ.baseを指すようにしてください。テーブルビューで子を親の下にネストするには、views[i].plainva.subItemsPropertyをbareな親リレーションキーに設定してください。循環参照は処理されます。サブアイテムを無効にすると、行はフラットのままで値は保持されます。

index.md（フォルダーの目次）

index.mdはフォルダーの目次のための予約名です。

• フロントマターを持てるのはルートのindex.mdのみで、それもokf_versionのみです——保管庫が従う規約のバージョンです（現在は"0.2"；これは保管庫をOKFアクティブとしてマークします）。まだ"0.1"を宣言している保管庫は設定 → 保管庫 → コンテンツと構造 → バンドルのバージョン → 更新…で引き上げられます。旧okf_versionフィールドは同じ手順でノートから削除できます。ルート以外のindex.mdはフロントマターがない状態でなければなりません——そこにフロントマターがあると予約名違反になります。
• Plainvaが管理するindex.mdは、マーカー<!-- plainva:index generated -->（HTMLコメント、閲覧モードでは不可視）で終わります。これが存在するということは、Plainvaがそのファイルを自動的に最新の状態に保つことを意味します。そのようなファイルを手動で編集する場合は、マーカーを保持する（そして生成された形を保つ）か、意図的に削除してそのファイルを恒久的に引き継ぐかのどちらかにしてください。
• 生成される一覧は、* [タイトル](相対/url) - 説明の形式のリンクのセクションです。

フォルダー概要を手動で生成する場合、安全な選択はマーカーを追加しないことです——そうすればPlainvaがそれを上書きすることは決してありません。

グラフビュー（plainva.render: "graph"）

グラフビューは、ネイティブでないすべてのビューと同じように保存されます: type: tableにレンダリングヒントを加えたものです。そのオプションは同じviews[i].plainvaネームスペースの中にあります。

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      # 他のデータベースからこれらのエントリを指すリレーションを含める (例: プロジェクトのタスク)

すべてのグラフオプションキーは任意です。設定しない場合は完全に省略してください。Obsidianは同じファイルを単純なテーブルとして表示し、エラーを出してはいけません。

ボードビュー（plainva.render: "board"）は、追加でviews[i].plainva.boardColumnOrderを持てます——グループ化列キーのリスト（__UNGROUPED__は値のない列を示します）で、手動での列の順序を記憶します。選択/ステータスのボードでは、代わりにプロパティのoptionsを並べ替えます。設定しない場合はこのキーを省略してください。

ピンボードビュー（plainva.render: "pinboard"）

ピンボードは、ネイティブでないすべてのビューと同じように保存されます: type: tableにレンダリングヒントを加えたものです。そのキーは同じviews[i].plainvaネームスペースの中にあります。

views:
  - type: table
    name: Pinboard
    plainva:
      render: pinboard
      pinboardOrder:                  # 固定されていないカードの手動順序
        - "Notes/Groceries.md"
      pinboardPinned:                 # 固定済み；リストの順序 = セクションの順序
        - "Notes/Idea.md"
      pinboardFilterBy: note.labels   # チップバーのラベルソース；省略 = tags

ルール: 固定されたパスはpinboardOrderには重複して含まれません。どちらのリストにも含まれないカードは、新しいものから順に一番上に表示されます（作成日時基準）。ファイルが存在しなくなった、またはソースの対象から外れたエントリは無視され、次回の保存時に整理されます。ノートの名前が変更または移動されると、Plainvaは両方のリストのパスを自動的に再ターゲットします——外部ツールも同様に行う必要があります。Obsidianはこれらのキーを無視し、ビューをテーブルとして表示します。

触ってはいけないものと安全性

• **.plainva/**はバックアップと内部状態を保持します。そこにプログラムロジックを読み込んだり、書き込んだりしないでください。
• 未知のキーは神聖です。 .baseやノートを書き直すときは、変更するつもりのなかったすべてのキーをそのまま引き継いでください。Plainva自身は内部の生コピーを通じて未知の.baseキーを保持します。サードパーティの書き手も同じことをすべきです（パースする → 意図したものだけを変更する → シリアライズする）。
• 値はノートで変わるのであって、.baseではありません。 セルを設定するには、ノートのフロントマターを編集してください。.baseはどのノートとどの列を表示するかだけを決めます。
• filters / formulas / properties / viewsを超えるトップレベルの.baseキーを追加しないでください。
• エンコーディング: どこでもBOMなしのUTF-8、LF改行。

関連ページ

• ノートとMarkdown — アプリ内で手書きするという視点から見た、同じ内容
• データベース (.base) — 日常使いのために説明されたデータベース
• OKF — type、バンドルのバージョン、OKF 0.2の信頼フィールド、index.md、そして保管庫の変換