属性是处理笔记开头的YAML的UI
在Properties中输入的名称和值会保存在笔记开头的frontmatter中。 例如，如果准备好status: 進行中，就可以在Dataview的WHERE条件下选择“进行中”的笔记。 和本文中写的普通文章的处理方式不同。
首先，决定要比较什么，然后使用少数项目。 在这个例子中，状态为status，优先度为priority，完成为done，期限为due，分类为tags。 作者制作的虚构记录，不是使用者的数据。
按顺序决定名称、类型、值
- 打开笔记，从Add property或官方的
Ctrl/Cmd+;中添加项目。 在实机例子中，点击Add property添加了priority。 - 按项目名旁边的类型图标，打开Property type选择类型。 在实机上选择Number，输入3保存。
- 现有的
status选择了Text，从“未着手”变更为“进行中”。 检查、Date输入、Tags输入也通过实际的UI进行变更，确认会反映在保存YAML中。 - Tags不只是输入文字就结束了，而是通过聚焦的输入按Enter进行确定。 这次的辅助操作也无法确定一次，再次通过Enter和焦点移动确认了保存。
| 名字 | 这个例子的类型和值 | 在实机上做过的事情 |
|---|---|---|
| 状态 | Text / 進行中 | Text选择，未着手→進行中 |
| 优先级 | 编号/3 | 添加项目，选择Number，输入3 |
| 完成 | Checkbox / true或false | false→true→false，最后是true |
| 到期 | 日期/2026-10-03 | 10月1日→10月3日 |
| 标签 | Tags / 验证、属性 | 添加属性确定 |
在官方资料中，同名的型号在整个保管库中是通用的。 在将相同的名称用于其他含义的值之前，先确认类型和用途。 List和Date & time等，这里没有处理的类型不包含在这次的动作确认中。
确认保存的frontmatter
下面是调查A的最后保存全文，211 bytes。 在GUI中将done更改为true后的状态，包括正文在内，内容与原Markdown相同。
查看调查A的保存Markdown全文
---
status: 進行中
tags:
- 検証
- プロパティ
done: true
due: 2026-10-03
priority: 3
---
# 調査A
著者が検証用に作成した架空の記録です。顧客データではありません。
在官方资料中，frontmatter用---包围文件开头，以名前: 値的YAML格式进行描述。 属性名称不会在一个笔记中重复。 这个例子的数值3和检查true分别保存为数值和boolean。 Date是保存这个值的确认，不是验证所有日期格式和输入的正确性的结果。
将相同的值作为TABLE和LIST的条件
在实机中，将官方Dataview稳定发布的三个文件事先复制到隔离的保管库中，通过实际的信任确认激活了插件。 这不是验证Browse/Install的画面操作的记录。 插件为了执行第三方代码，确认分发来源和使用条件后进行选择。
发布名称是0.5.70，分发manifest和实际画面的显示版是0.5.68。 需要的Obsidian最小版是manifest上的0.13.11，实际运行的Obsidian是1.13.7。 DataviewJS设置是false，将下一个DQL输入到实际编辑器中，在Reading view中显示。
文件夹名記録、项目名、状态字符串一致。 调查A/B正在进行中，C已完成。
# Properties接続検証
著者が作成した架空の3件だけを表示します。
## 進行中の表
```dataview
TABLE status AS "状態", priority AS "優先度", done AS "完了", due AS "期限"
FROM "記録"
WHERE status = "進行中"
SORT file.name ASC
```
## 未完了の一覧
```dataview
LIST
FROM "記録"
WHERE done = false
SORT file.name ASC
```
## 保留の該当なし
```dataview
LIST
FROM "記録"
WHERE status = "保留"
SORT file.name ASC
```
TABLE将正在进行的两件列为表，LIST将done将false的笔记列为列表。 最后的LIST选择了保留的笔记，也确认了没有对象的情况下的实际显示。 DQL的全部功能、内联字段、DataviewJS没有在这里尝试。
更改完成检查后，未完成列表从2件到1件
| 条件 | 调查A的done=false | 在GUI中更改为done=true后 |
|---|---|---|
| status = 進行中的TABLE | 调查A・B / 2件 | 调查A・B / 2件。 显示A的完成值true |
| done = false的LIST | 调查A・C / 2件 | 调查C / 1件 |
| status = 保留的LIST | 不适用 | 不适用 |
变更前的TABLE两件用实际Reading DOM确认了，当时的PNG从表向下滚动。 上面的变更后，在PNG中可以看到表两件和未完成一览一件。 没有重新制作并替换显示位置和图像。
从文件一览表中再次打开调查A和一览表笔记，也确认了保存Markdown的bytes和SHA256相同。 同一应用程序启动中重新显示，不是整个应用程序的重启或确认其他终端。 在这次的条件下，数值反映在显示上，没有测量工作速度和生产力提高的因果关系。
保存最终状态的四个文件
是将实机保存的原Markdown的bytes原样复制的文件。 调查A的done是true。 在以下配置中，查询的FROM和文件夹名是一致的。 读者在保管库的导入尚未验证。
保管庫/
一覧.md
記録/
調査A.md
調査B.md
調査C.md| 保管库内的相对路径 | 保存原件 |
|---|---|
記録/調査A.md | 保存調査A.md（211 bytes） |
記録/調査B.md | 保存調査B.md（152 bytes） |
記録/調査C.md | 保存調査C.md（150 bytes） |
一覧.md | 保存一覧.md（472 bytes） |
三记录的初期内容在验证前直接制作。 调查A的项目变更和列表笔记的查询输入是GUI操作的范围。 不会把B/C作为GUI从头开始创建的记录。
常见问题
Obsidian的属性和frontmatter是不同的数据吗？
属性的类型是按笔记设置的吗？
在Dataview中列出属性的基本形式是什么？
下载的例子是什么状态？
官方资料和这个实机确认的范围
GUI确认的UTC日是2026年9月30日，日本时间是2026年10月1日。 实际画面、保存原件、固定来源、辅助的更正、结束记录的不足总结为验证记录。 虽然发送了结束Close，但根据记录器的结束顺序，Obsidian的结束代码未记录。
- 已确认：Linux Obsidian 1.13.7，五种类型的有限GUI操作，保存YAML，DQL三条件的实Reading显示，值变更和重新显示，同一启动中的保存一致。
- 官方说明：Properties的保存形式、类型的共享，用固定资料确认Dataview的frontmatter/QUERY/TABLE/LIST/WHERE。
- 未确认：全型・全输入验证，插件的安全审核，全DQL/JS，应用程序重启，iOS，同步，SimpleMemo配合，大保管库·速度·生产力。