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?

2 Likes

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

yeah properties do have a cumbersome syntax:

:PROPERTIES:
:type:
:END:
1 Like

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)

4 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

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?