Are you using, and if so, how are you using **Block** Properties?

[FlorianF]

Just curious how do you get value out of Block Properties. I don’t seem to have much luck in finding info online on this.

Thank you.

[da5nsy]

Hey Florian!

I’m sure there are a bunch of different uses, but for me I use them in task management like this:

TODO Insert example task
headspace-required:: low

where the value for headspace-required can be low/medium/high

Then I have a TODO page with a query set up with queries like this:

{{query (and (task TODO) (property headspace-required low))}}

which enables me to think “huh I’m feeling kinda **** today, but I still wanna do something, what’s on my headspace-required low list?”

Sadly the list is often empty… but that’s a different story

[Siferiax]

I use them … a lot… for a lot of different things… some a little bit more private than others

My games page is probably the most notable example though.

All queries use the status property to filter which games are shown. And all results display properties as columns, considering properties are the only columns available really.

My projects list works in a similar way. As well I have some more sensitive data, but that uses properties similarly.

Outside of building queries with table results, I also use it for simple visual distinction.

[FlorianF]

@Siferiax So you are using blocks to rate a game whenever you played it? I can’t infer the block from your properties table (maybe share a pic if the actual blocks? ). I am curious about use cases for block properties usage and, more specifically, I want to get a good understanding on use cases when these properties change over time and I want to see a graph of the evolution of the score for a game or whatever over some time.

I assume that some important Blocks that use Properties are going to end-up as templates so you can insert it into the daily journal whenever needed and state new values for the pre-defined properties.

[Siferiax]

@FlorianF

So you are using blocks to rate a game whenever you played it?

Not actually as I play them. This is really just a status of the game as a whole.
So things like do I own the game, did I play it, did I finish it to the credits, did I do extra content or dlc.

@FlorianF

I can’t infer the block from your properties table (maybe share a pic if the actual blocks? ).

They are page properties actually and just get filled in over time.
So here’s an example of what such a page looks like.

Here’s what “afgerond” (finished) as a table and single game would look like.

(some games have notes on their pages so I’m deliberately showing games without them for spoilers)

I also use properties in blocks for my note taking. More info on that can be found here:

Changing the way I make notes

Which would be a follow up on this answer I gave in another conversation

Storing information on journal pages vs dedicated files

I think the first step would be defining what value you are looking to get out of it. I like to approach my workflow not as something to optimize, but instead tweak when necessary. So if I bump into something that isn’t working for me, I analyse why and then figure out a different approach to reach a better workflow. Otherwise, it is good enough as is. Yeah, here’s an example of what I had. [image] And maybe it would branch off further so I would have [description](link) to one of the s…

[falken]

I like this idea. People see me as first and foremost a gamer even though there are many other things I consider more important about me

I have almost 100 platinum trophies on the Playstation Network and quiet a large collection on Steam too, but never occurred to me until now to document my experiences with them in such a way.

[FlorianF]

@Siferiax

Changing the way I make notes | Sif's blog

This is very insightful. Thanks for posting. I am contemplating also about using templates for journal blocks/notes in which I would actually start using properties. ATM I am heavily using Tags because they are more universal to markdown sharing and viewing in other tools so this would be a departure from that. Or I might just use both, for compatibility, which seems redundant and friction-inducing. Or maybe properties as tags can be interchangeable (they point to a page anyway).

Hmm… just tried that … I can’t use a hashtag for a property name, it expects a text with no spaces that it transforms into a Logseg Page (WikiLink). So, if I write a property like quote:: it will actually link it to the Logseq Page quote.md, which is the same target as [[quote]] or #quote. In this regard my tags seem more like Values for the Properties than the actual properties names. I would create a property called Type:: where Quote would be its Value. For compatibility, I would also have a Tags:: property where I am still placing the tags in hashtag format.

So from what I can tell the power of properties comes from 3 sources:

1. they show up in a nicely formatted table in queries (Logseq-specific);
2. they can have values that can be sentences, links, LaTEX, multiple values, whatever (which can get super-handy);
3. they can refer actual Tags that can be used outside of Logseq;
4. ? maybe there are more …

So they -from the start- can organize information and hold more data than Tags.

It then hit me: maybe the whole bullet can only be made of properties and that will get it so much closer to a database where there are key:value pairs that can be queried. I don’t know how this would go for complex blocks (with lots of child blocks - maybe each child block, being a bullet itself, will have its own properties) but I will try experimenting to see if there is any way to at least contemplate such an option. At least for simple notes it should be totally feasible to have properties-only blocks. It’s just a pity we can’t have multi-line properties and markdown rendering in Logseq for properties but, as I said, for simple notes it should work ok, apart from rendering, which doesn’t look elegant if we can’t have some sort of markdown syntax inside properties.

[Siferiax]

@FlorianF

it expects a text with no spaces that it transforms into a Logseg Page (WikiLink). So, if I write a property like quote:: it will actually link it to the Logseq Page quote.md, which is the same target as [[quote]] or #quote.

Yeah I dislike this and turned it off in the config file.

;; Create a page for all properties.
 ;; Default value: false
 :property-pages/enabled? false

@FlorianF

I would create a property called Type:: where Quote would be its Value.

That would be the more logical use of properties yes.

@FlorianF

It then hit me: maybe the whole bullet can only be made of properties and that will get it so much closer to a database where there are key:value pairs that can be queried.

That’s what properties are at this point. Key:value pairs. In queries they work that way as well.
[?b :block/properties ?prop] get all the properties associated with the block. That gets you a key:value pair list (vector/set whatever the case)
[(get ?prop :key) ?value] get a specific key from that list and store it’s value in ?value.
Value can then be a list/vector/whatever the term in and off itself. For example when you have multiple tags. (tags:: tag1, tag2)

[FlorianF]

Yes, pretty common sense when you say it … but I’ve had much battling with 1) making it play nice with external apps (static site generators, etc) and 2) extract some good value from such properties. First one I pretty much nailed today after too many hours of fiddling with. The second will come with experience I guess…

For now an example:

, which renders quite OK, and usable in extrnal parsers (this is Firefox Add-On):

Edit: of course I’d hide the query or not have it in the same .md file in the first place