How to use properties and templates in Logseq

TL;DR

Logseq properties store structured metadata using a subject–predicate–object pattern entered with `::` (subject = page/block content, predicate = property name, object = value).

Briefing Cornell Notes

Briefing

Logseq’s page and block properties are turning metadata into a practical search engine—especially when paired with templates that force consistent input. Instead of relying on plain text links (“this is linked”), properties let users specify relationships (e.g., “lives in: Australia”) and then query that structured information later, making retrieval faster and more reliable as databases grow.

Properties in Logseq work like database fields, but they’re stored using a semantic triple pattern: subject–predicate–object. The subject is the page or block content being described, the predicate is the property name (properties must be one word, typically entered as `::`), and the object is the value. In the example, a “John” page gets properties such as `lives in:: Australia` and `birthday:: 18th of July 1989`. A second page for “Kerry” uses the same predicates with different values (e.g., `lives in:: England`, plus a separate date property). Logseq also supports property creation and reuse via autocomplete—typing `::` and then selecting an existing property name or value.

The workflow split matters: page properties must be the very first block on a page, shown in a distinct gray metadata block. If properties appear later, they become block properties instead. Block properties attach metadata to a single block, not an entire page, and a single block can hold multiple properties. This is where the biggest practical shift happens: adding metadata at the block level avoids creating hundreds of separate pages for items like imported articles. In the transcript’s example, an “articles” database is stored as blocks inside a journal-like page, with each article block carrying properties such as type (input/output) and a link. That structure enables powerful filtering and querying without cluttering the system with extra pages.

Block properties also demand correct structure: properties must be indented under the block header they belong to. A “bad” layout—where property lines sit in separate blocks—breaks the intended grouping and makes later retrieval unreliable. When done right, properties improve link meaning by specifying how two things relate, and they unlock more precise queries down the line.

Templates then reduce the friction of entering that metadata consistently. Templates are pre-designed arrangements of blocks that act as starting points, saving time and encouraging users to fill in required fields instead of postponing them. The transcript highlights a setup approach: store templates in a dedicated “templates” page, and optionally use Logseq config (`default templates`) to make a daily template appear automatically. Example templates include meeting notes (with event/project properties and standardized bullet sections), article templates (standardizing imported article structure), and review templates with recurring prompts.

Overall, the core message is that properties—especially block properties—make Logseq databases searchable and maintainable, while templates ensure the metadata needed for that search is entered every time.

Cornell Notes

Logseq properties add structured metadata using a subject–predicate–object pattern, entered with `::` (e.g., `lives in:: Australia`). Page properties must be the first block on a page; otherwise they become block properties. Block properties attach metadata to a single block and can include multiple fields, enabling precise queries and reducing the need to create many separate pages (e.g., storing imported articles as blocks with properties). Templates then standardize data entry by providing pre-built block layouts, cutting repetitive typing and encouraging consistent metadata input. Together, properties and templates turn links into relationship-aware, queryable data.

How do Logseq properties map to a database-style model, and what does the subject–predicate–object structure mean in practice?

Properties function like database fields/columns. In Logseq, they follow a semantic triple: the subject is the page or block content being described, the predicate is the property name (entered as a one-word token after `::`), and the object is the value. Example: for a “John” page, `lives in:: Australia` makes “John” the subject, “lives in” the predicate, and “Australia” the value. Adding another property like `birthday:: 18th of July 1989` creates additional structured fields for the same subject.

What’s the difference between page properties and block properties, and why does placement matter?

Page properties must be placed as the very first block on a page; Logseq displays them in a distinct gray metadata block. If property lines appear later, they attach to the block where they’re written, becoming block properties. Block properties are metadata for a single block and can include multiple properties. This distinction affects how metadata is grouped and later retrieved.

Why do block properties require indentation under a block header?

Block properties need to be nested under the block header they belong to. If property lines are spread across separate blocks (a “bad” layout), the metadata no longer attaches to the intended block, which breaks later filtering and retrieval. The transcript emphasizes that correct indentation is what keeps all related metadata together under one block.

How do properties improve links beyond simple “linked” relationships?

Without properties, links often only indicate that two items are connected. Properties add specificity by defining the nature of the relationship—like “producer,” “type,” or “date created.” That specificity supports more powerful queries later, because the system can filter based on property values rather than treating links as undifferentiated connections.

How do templates reduce metadata “friction,” and what do good templates accomplish?

Templates are pre-designed arrangements of blocks used as starting points. They save time by avoiding repeated manual entry of the same structure (e.g., article headers, meeting-note sections). They also act as a forcing mechanism: users are more likely to input required metadata because the template prompts it immediately. Good templates justify their setup cost by being used often and by encouraging consistent, queryable data entry.

What’s the practical advantage of storing many items as blocks instead of pages?

The transcript describes a shift where imported content (like articles) is stored as blocks within a single page rather than creating a separate page for each item. With block properties (e.g., article type and link), the system can still retrieve items precisely. This avoids database clutter (hundreds of extra pages) while preserving queryable metadata.

Review Questions

When would a `::` property you type become a page property versus a block property in Logseq?
What structural mistake can prevent block properties from being discoverable later, and how does indentation fix it?
How do templates change user behavior around entering metadata, and what kinds of templates were given as examples?

Key Points

1
Logseq properties store structured metadata using a subject–predicate–object pattern entered with `::` (subject = page/block content, predicate = property name, object = value).
2
Page properties must be the first block on a page; otherwise they attach to the block where they appear.
3
Block properties attach metadata to a single block and can hold multiple properties, enabling fine-grained search and filtering.
4
Correct indentation is essential: block properties must be nested under the block header they belong to, or they won’t group correctly.
5
Properties make links more meaningful by specifying relationship types (e.g., “producer,” “type,” “date created”), enabling more precise queries.
6
Templates reduce repetitive input and encourage consistent metadata entry, improving long-term retrievability of information.
7
Storing many items as blocks with properties can prevent database bloat from creating hundreds of separate pages.

Highlights

Properties use a semantic triple—subject, predicate, object—so relationships become queryable, not just linked.

Page properties only work reliably when they’re the first block on a page; later placement turns them into block properties.

Block properties can replace page-per-item workflows by storing imported content as blocks with metadata for later retrieval.

Templates act as a forcing mechanism: they reduce friction and make consistent metadata entry more likely.

Indentation under the correct block header determines whether block properties attach to the intended block.

Topics

Logseq Properties
Page Properties
Block Properties
Templates
Metadata Queries