Roam has the feature of using double colon to define properties
For example
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?
I don’t use properties heavily, but this sounds good to me.
yeah properties do have a cumbersome syntax:
:PROPERTIES:
:type:
:END: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:
(page-property key value)
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)
Do we differentiate between these two properties?
the ones you see if you click on sample.md link on a page - then it shows you something like this:
----
title: sample
----
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:
abc::, hij::. First character cannnot be an underscore “_”_ls-core-collpased::, _ls-pluginnamespace-propertya::, etc. Starts with underscore “_”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?
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)?
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]].
These links don’t work. Maybe logseq is not the best system for hosting documentation yet.
The correct link is https://docs.logseq.com/#/page/term%2Fproperties. Logseq now shows the page names in the URL when linking to public graphs. I’ve updated the link in @Joe_Smoe’s comment.
Anyway, I agree with your comment on hosting documentation within Logseq. Now everything should go there, that’s why I’ve added the #docs category on this forum.