Plainva

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

最終更新: 2026-10-22

このページは、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. UTF-8で書いてください。新しいファイルはLF改行・BOMなし、すでにあるファイルは今の改行とBOMのままにします。 Plainvaも同じです。Plainvaが作るファイルはLF改行でBOMなしで始まり、見つけたファイルは改行もBOMもそのまま保ちます — ノートを編集しても、変わるのは変更した行だけです。2種類の改行が混ざったファイルは、最初に編集したとき、行の多数を占めるほうの改行にそろえられます。CR（復帰文字）だけの改行 — 古いMacのファイルの改行 — は読み込まれますが、そのままは保たれません。そのようなファイルを最初に変更したとき、PlainvaはLF（ほかの改行の多くがCRLFならCRLF）で保存し、そのことを知らせます。

保管庫の全体像

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

ファイルそれが何かテキストとして編集可能か
*.mdノート: YAMLフロントマター + Markdown本文はい
*.baseノートに対するデータベースビュー（YAML）はい
index.mdフォルダーの管理された目次（予約名）はい、注意が必要——index.mdを参照
log.md予約名、現在は未使用触らないでください
画像、PDFなど添付ファイルいいえ（バイナリ）
.plainva/Plainvaの内部フォルダー（バックアップ、状態）いいえ——絶対に触らないでください

予約名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

ブロックは空でもかまいません。---の直後に---が続く場合、それは2本の区切り線ではなく、プロパティのないブロックです。ノートの本文はその次の行から始まります。Plainvaは空のブロックを残しません。最後のプロパティを削除すると、2つの---行も一緒に削除されます。本文自体が---行で始まる場合に限り、その行がブロックの開始として読まれないよう、2つの行は残ります。

Plainvaがプロパティとして読み取れないブロックは、そのまま残されます。2つの---行の間にあるYAMLではないテキストや、キー: 値の行ではなくリストになっているYAMLがこれにあたります。プロパティは、プロパティがないと表示する代わりにそのことを示します。そのようなノートのプロパティをそこで、またはデータベース、ピンボード、タスク一覧で変更しても、またアイコンや色を変更しても何も変わらず、Plainvaはそのことを知らせます。プロパティを保存できませんでしたに続けて理由が表示されます。ノートのテキストでブロックを修正すれば、変更できるようになります。想定外の形式の値が1つあっても、ブロックが読み取れなくなることはありません。Plainvaはその値を書かれているとおりに読み取ります。空のtags:はタグのないノート、タグの中の数値（- 2024）はタグ2024、titleの数値はそのタイトルになり、日付だけのtimestampはほかと同じプロパティになります。

OKFフロントマターフィールド

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

フィールド型意味
type文字列このドキュメントがどのような種類か（Note、Daily Note、Projectなど）。OKFが実際に要求する唯一のフィールドです。
generated、verified、sources、stale_after、status下記参照OKF 0.2の信頼とライフサイクルのフィールドです——すべて任意です。このセクションの直後の「信頼とライフサイクル」を参照してください。
okf_version文字列ルートのindex.mdのみ: 保管庫全体がどのバージョンの規約に従っているかを示します。例: "0.2"（YAMLが文字列として保持するよう引用符で囲みます）。Plainvaは以前（OKF 0.1まで）はこのフィールドを個々のノートに書き込んでいましたが、0.2以降はもう書き込みません。既存のエントリはエラーではありません——バンドルの更新で希望に応じて削除できます。

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

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

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

フィールド形意味
generatedオブジェクト { by, at }誰がいつノートを作成したか。atはUTCのISO 8601形式の時刻です（2026-08-21T10:11:12Z）。
verified{ by, at }のリスト誰がノートをレビューしたか。すべてのレビューが追記されるためリストになっています——レビュー履歴は残り、最新のエントリが有効です。
sources{ resource, id?, title?, … }のリストノートが何から作られたか。resourceは識別子です（URL、メールのmid:<Message-ID>、ファイルパスなど）。追加のキーも許可されます。
stale_after日付（2026-12-31）または時刻内容がいつから失効とみなされるか。純粋な情報です——Plainvaはヒントを示すだけで、何も変更しません。
statusdraft | stable | deprecatedライフサイクルの状態。正確にこの3つの値のみが有効です。draftとdeprecatedは帯表示として現れ、stableは表示されません。

アクター（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
---

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

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

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

プロパティタイプYAML形式例
テキストスカラー文字列title: Hello
数値数値priority: 3
チェックボックス真偽値done: true
日付ISO日付文字列due: 2026-07-20
日付と時刻ISO日時文字列at: 2026-07-20T14:30:00
リスト文字列のYAMLリストauthors: [Ada, Alan]
タグ文字列のYAMLリストtags: [project, active]
選択 / ステータス単一のスカラー文字列status: Done
複数選択文字列のYAMLリストlabels: [urgent, later]
URL / メール / 電話スカラー文字列site: https://example.org
リレーション（単一）Wikiリンク文字列project: "[[Project Alpha]]"
リレーション（複数）Wikiリンク文字列のYAMLリストrelated: ["[[A]]", "[[B]]"]

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

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

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

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

キー値意味
icon絵文字グラフェム、またはlucide:<kebab-name>ドキュメントアイコン（Notion風）
icon_color16進カラー（#rgb / #rrggbb / #rrggbbaa）lucide:アイコンの色合い（絵文字はこれを無視します）
header_color16進カラー全幅のヘッダーストライプ
tasksfalseこのノートのチェックボックスをタスクビューから除外する
templateFor.baseファイルへのWikiリンクのリスト記載されたデータベースにテンプレートを割り当てる（テンプレートフォルダー内のノートでのみ意味を持つ）
pimマッピング（下記参照）ノートを外部のカレンダーの予定・タスク・メールに結びつけるアンカー

これらはすべて任意です。どれも書かない場合は、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は不要です。recurring: trueは、プロバイダーがタスクを再び戻してくる（完了したあと、同じuidのまま、より後の日付で再び未完了になる）のをPlainvaが確認した時点で、タスクのアンカーに追加されます。このキーは情報提供のためだけのもので、比較には使われず、削除してもかまいません。

ファイル名は識別情報の一部ではありません。 反映されたタスクはタイトルが名前になり（<タイトル>.md、同じタイトルなら <タイトル> 2.md など）、対応付けはアンカーだけで行われます。アンカーが残っている限り、ツールはファイルの名前を変更したり移動したりできます。<タイトル> — <16桁または64桁の16進数>.md という形式の名前は、2026年9月12日〜24日のPlainvaのバージョンによるものです。この数字は、プロバイダー、識別情報、リスト、uid から計算したSHA-256の先頭部分です。タスクビューでは、数字が同じファイルのアンカーと一致する場合に限り、タイトルに基づく名前への変更を一度だけ提案します。

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

リンク

依存関係（blockedBy）

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

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

データベース (.base)

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

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

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

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

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

場所形式例
properties:マップのキー接頭辞付きnote.status、file.name
ビューのorder:リスト接頭辞付き[file.name, note.status]
ビューのsort[].property接頭辞付きnote.due
フィルター式の中barestatus == "Done"
plainvaサブキーの中（groupBy、dateField、endField、subItemsProperty）baregroupBy: status

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

トップレベルキー

plainva:サブキーマップ

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

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

キー値意味
input下記の入力タイプのいずれか列のフィールドタイプ
optionsオプションオブジェクトのリスト選択/ステータス/複数選択のキュレーションされた値
relationBase保管庫相対の.baseパスリレーションの対象データベース（リレーションを参照）
relationLimitoneカーディナリティ: 単一リンク。省略すると無制限。
reverseOf{ base, property }計算された逆リレーション列（inputなし）を示す
rollup{ through, of, fn, where }計算されるロールアップ列であることを示します（input は持ちません）— 下記を参照
previousKeys以前の素のキーの一覧（最大 8 件）名前変更の痕跡: この列に留められた注釈が、名前変更後もこの列を見つけられます。保持してください。項目を勝手に作らないでください。

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

キー値意味
renderboard / calendar / timeline / graph / pinboardPlainva専用のビュー種別（下記参照）
groupBybareなプロパティキーボードのグループ化列
dateFieldbareなプロパティキーカレンダー/タイムラインの開始日
endFieldbareなプロパティキータイムラインの終了日
coverImagebareなプロパティキーギャラリーのカバー画像プロパティ
subItemsPropertybareなプロパティキーサブアイテムのネスト用のセルフリレーション親列
widthsid → pxのマップ列幅
dateFormat文字列ビューごとの日付形式（defaultは暗黙——省略してください）
boardColorModecolumnボード: 列全体をそのグループの色で着色します（chip——見出しのチップのみ——は既定なので省略します）
boardLaneBybareなプロパティキーボードのスイムレーン: 二つ目のグループ化の軸
boardWipLimitsグループの値 → 数値のマップボード: 列ごとの仕掛かり上限
colorBybareなプロパティキータイムラインのバーとボードのカードが、このプロパティのオプションの色になります（ボードではノート自体の色が優先されます）
pinboardOrder保管庫相対パスのリスト固定されていないピンボードカードの手動順序
pinboardPinned保管庫相対パスのリスト固定されたカード。リストの順序がセクション内の順序になります
pinboardFilterBytags、またはbareな複数選択キーピンボードのチップバーのラベルソース（tagsは暗黙——省略してください）

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

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

キー値意味
fileIconColor16進カラーデータベースアイコンの色合い（ツリー/タブ/ヘッダー）
newItemFolder保管庫相対のフォルダー「新規作成」ボタンが新規項目を保存する場所
newItemTemplate保管庫相対の.mdパス新規項目のデフォルトテンプレート
contextFiltersbareなプロパティキーのリスト自己参照フィルター（「このノート」）——下記を参照
taskList"<アカウントid> <リストid>"新しいタスクも一緒に作成される提供元のタスクリスト——下記を参照

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  rating  checkbox  date  datetime
select  status  multiselect
list  tags  url  email  phone
relation

計算された逆列にはinputがありません——reverseOfによってのみ識別されます。 rating 列はファイルに単純な数字を保ちます（mood: 4）。表示はマークです。任意のサブキーが二つあります：

    note.mood:
      plainva:
        input: rating
        ratingMax: 5        # 1～10、既定は 5
        ratingGlyph: "★"      # 1 文字、既定は点

並べ替えも絞り込みも number と同じです。Obsidian は rating を知らず、列を数字として表示します —— 実際そのとおりです。

file.day は仮想フィールドです。Vault のフォルダーと形式に従って、デイリーノートのファイル名が表す日付です。どのノートにも書かれず、問い合わせ時に計算され、読み取り専用です。使えるのはカレンダーまたはタイムラインビューの dateField だけです。Obsidian はこのフィールドを知らないので、これを使うビューは向こうでは空になります。

ロールアップ

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

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

オプションと色

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

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はそれらを単純なテーブルに縮退させます。

あなたが望むものディスク上のtypeplainva.render
テーブルtable—
リストlist—
ギャラリーcards—
ボードtableboard
カレンダーtablecalendar
タイムラインtabletimeline

フィルター

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

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

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

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

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

演算子式
等しいstatus == "Done"
等しくないstatus != "Done"
含むcontains(labels, "urgent")
含まない!contains(labels, "urgent")
より大きい / より小さいpriority > "2"、priority < "5"
以上 / 以下priority >= "2"、priority <= "5"
空であるstatus == ""
空でないstatus != ""

構造（単一ルート！）: 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:キーがないことに注目してください——逆側は計算されるものであり、決して保存されません。

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

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

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

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

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

フォルダー概要を手動で生成する場合、安全な選択はマーカーを追加しないことです——そうすれば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はこれらのキーを無視し、ビューをテーブルとして表示します。

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

関連ページ

ヘッダーの色 / アイコン / タグ · ノート全体

色の帯、アイコン、ノート全体のタグ、またはピンボードで設定したラベルのプロパティで絞り込めます。タグは完全一致です。#workは#workshopや#work/childには一致しません。本文とfrontmatterのタグを合わせます。結果が0件でも選択肢は元の全体から取得し、不明なアイコン名も保持します。

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")'

タスクのプロパティ: 時刻、優先度、リマインダー、状態

ジャーナルエントリ