Use :: to define properties

Roam has the feature of using double colon to define properties
For example

  • Status:: #active

This is useful as properties can be queried

I find the current way to write properties very powerful. However, for simple cases the Roam approach makes it very simple to write, which I appreciate.

What do you think?

4 Likes

I don’t use properties heavily, but this sounds good to me.

1 Like

yeah properties do have a cumbersome syntax:

:PROPERTIES:
:type:
:END:
2 Likes

It’s already supported in the Canary release. The syntax is something like:

property-A:: value
property-B:: value

Notice there’re some differences between Logseq and Roam:

  1. The first block’s properties will be treated as page’s properties so that we can query use (page-property key value)
  2. Each block in logseq can have an optional title, for example:
Title (which is optional)
property-A:: value
property-B:: value (properties are optional too)
Body content (which is optional too)

Blocks can be queried using property too. (property key value)

7 Likes

Do we differentiate between these two properties?

  1. the ones you see if you click on sample.md link on a page - then it shows you something like this:

     ----
     title: sample
     ----
    
  2. the property in the first block of a page

1 Like

The front matter attributes are still supported for backward compatibility, both front matter attributes and the new properties are merged and stored as the page’s properties.

The terminology is a little unclear to me. Which ones are the front matter attributes and which are properties?

These are front matter:

 ----
 title: sample
 ----

These are the new properties syntax in logseq:

property-A:: value

Fantastic! This will tie in well with Dataview for Obsidian too…

Is possible to allow clicking a property and be able to go to a page with property’s name and have al pages using such property as back reference links. Roam allows this.
It’s useful to browse all properties vales and where they are used in.

A question? How to differentiate between user properties (my domain properties) and program/future plugin properties?

For example, if I want a property named collapsed be attached to a block because has a meaning to me in the context of the content of a document. How to do that and don’t cause problems with internal collapsed property used by block collapsing?

Also, in the future, If I’m using a property named abc and some future plugin uses it for another thing, how can we handle these conflicting situations?

And if Logseq supports clicking a property (like a page) to show linked values and pages (like Roam does), Logseq and plugins properties should be forbidden to do that operation (or at least a plugin can allow some properties to be clicked and others not).

What about using some type of prefix/namespace for properties to indicate when a property is an user property, a logseq/plugin property not treated as page and one that can be clicked like a page?
For example:

  • user property: abc::, hij::. First character cannnot be an underscore “_”
  • logseq/plugin property (not clickable like a reference): _ls-core-collpased::, _ls-pluginnamespace-propertya::, etc. Starts with underscore “_”
  • logseq/plugin property (clickable like a reference): ls-core-collpased::, ls-pluginnamespace-propertya::. If an user types a property startting with ls- must to know that in the future can have conflicts with logseq or plugins properties.

What do you think?

1 Like

Where is this documented aside from a mention of a canary release from over a year ago? Throughout the main logseq documentation the use of colons is inconsistent and the optional title and body are nonexistent (as far as i can tell). Am I to understand this would all go in a single block (with no bullet points to the left of it)?

https://docs.logseq.com/#/page/term%2Fproperties - hopefully this helps you out

Not really, sorry - I could find this page and did read it, but where is the documentation about the optional title and body before and after the properties in the same block? I know i saw that somewhere but it’s not clear from here.

I’m interested in learning more about what @Zab asked. I want to compute and store some meta data on pages when they’re updated from a plugin. Ideally I’d like this data to be hidden from view, and in a namespace belonging to the plugin. Is this possible @tienson ?

Also curious if there is any size limit for how much data I can put into a property?

Page properties are defined in the front matter “the first block of a page” – link

The title property key must be defined in the page-property block (block-properties will have no affect on the title key) – link

The old style of block-properties is no longer recommended after Beta version was launched – link

So to define a title property-key and to include some body text in the page-property, you would put the contents below inside the first block.

title:: My new page name
Body text will go here

In the documentation for properties:

When a property value matches an existing page title, Logseq will automatically create a link to that page

This hasn’t worked for me, unless I’m missing something. I have a page named “apple”, but typing key:: apple as a property for a block doesn’t turn it into [[apple]].