Thank you, I have updated the post.
This is very confusing. I have spent 10 minutes completely confused with my logseq database, trying to see some results while typing these. The problem is, I failed to catch any query with page-property in it. Is it still in logseq, or has it been deprecated since??
Still works.
If you use the live query builder and first select pages at the top right, then page property you should get a list of page properties you have in use.
If that list is empty, then you have not yet (properly) defined any and so queries will not return results.
2 Likes
ah, then, that was it. I was not aware of that distinction on the top right that I had to pick “page property” specifically.
1 Like
page-properties are fairly useless in my opinion because you can select the page to show on a blockquery. The only thing to get this working always is you have to avoid using page-properies (properties in the first bullet of the page).
Personally I would prefer that all properties are just properties and that there is no difference between the two. That would make the use of properties a lot easier instean of an arbitrary difference between page-properties and block-properties (wether or not it is in the first bullet is the only difference).
1 Like
As a result of my experiments with them, I am on my path to forming this opinion, as well. I simply do not understand what additional capability page properties brings to the table, when we have block properties. Block properties seem to do everything page properties does, and more (because block properties also apply to the blocks within a page where they are specified, as opposed to page properties, which seem to apply only to the page names (?)).
Exactly. Now I am trying to wrap my head around the difference between the two, but my experimentation with logseq is failing to show me any substantial difference between the two.
Exactly.
Edit: I found this post also helpful in seeing whether there is much diff between page-/block-properties:
page properties vs block properties
not that different honestly, except some built-in page properties have additional functions apart from being basic properties such asaliastagsandiconbut he difference is mainly because those are the built-in ones
the other minor difference is when you’re querying you can target page-tags specifically
Thanks for the clarification, as I was confused about this whole “inheritance” stuff.
So, is there actually any property that gets “inherited” ?? I am failing to find some demonstration for that case.
Edit: “Block properties are not inherited while page properties are.” → this seems to be true.
Not sure what you mean exactly with this?
I think the most important difference between the two is when we query pages and put things in table view. It is then that we can select what page properties we wish to see.
I’m not sure if it would be better to show all properties from all blocks available on the page.
In advanced queries we see that there is no inherent difference in how these two things are stored.
Whether ?var is a block or page, if I want its properties I call on the attribute [?var :block/properties ?prop] (where the value of the attribute gets stored in the variable ?prop)
It is then Logseq who interprets things in two different ways. This is what we see in simple queries as well as how things are displayed and processed.
3 Likes
But can’t you use Block Properties for getting table view, too? I think I am doing that already. So, I can also get a table view for a query of mine, when I use Block Properties. So, what is the real differentiating use-case for Page Properties?
Super simple example to illustrate what I mean.
I have two page, page 1 and page 2 as such:
When I query for these pages, this is the resulting table.
I hope that illustrates better what I was getting at?
Properties can be used to organize pages exactly like blocks. In the table view the rows can be pages or blocks. It’s exactly the same to me and both are useful for similar purposes. 🤷🏻♂
2 Likes
This is exactly what I mean …
When you do a blocks query looking for all values of a-property you will get the correct table. Like below …
And when I do a pages query I only get 1 value. So I am unable to recreate your example and that is problematic because it is an extremely simple example but we get already differrent results !!!
Correct table is subjective.
I don’t query based on the property, I query based on the page.
My query is very basic as I was just trying to illustrate my earlier comment.
So it basically says give me page 1 or page 2.
Namely the point I was making is. What properties do we expect to show up as possibilities when querying for pages?
All properties of all blocks on the page would make for a miserable UI in my opinion. And therefore being able to have properties for the page is important.
As I already mentioned they are stored the same way. They are just visualized differently.
Any block query based on properties doesn’t care whether they are page or block properties.
However any page query does. And it should in my opinion.
The simple query syntax makes that difference in a similar way. It’s just less intuitive in my opinion. But I haven’t thoroughly tested simple queries.
I really don’t see how page properties are “different” than block properties. A page, is a block with a name, after all.
Thus, I don’t understand why seeing “all properties of all blocks” would be miserable UI? I mean, let’s say it would be miserable. But then, at least it would be a CONSISTENT UI, that wouldn’t confuse the user.
They aren’t inherently different. They just show up different in both UI and simple queries. In the data they are stored in the same attribute of the entity whether that entity is a page or block doesn’t matter.
It would not be. As when we query a block, similarly we do not see all properties of its child blocks.
It follows the same logic.
And so if we apply that the other way, just as a block can have properties regardless of its children. So too should a page be able to have properties regardless of its blocks.
They may be the same but it is strange that the first bullet reacts differently. Suppose I have a journal for a day for I day I did nothing except watching 3 movies.
So my journal for that day would be like this.
- movie:: Movie 1
score:: 5 - movie:: Movie 2
score:: 7 - movie:: Movie 3
score:: 8
then the Movie 1 block would be a page-property and the other 2 would be just a property. That is totally not logical nor consistent UI.
An extra disadvantage is that when you do want to use page-properties (I fail to see why you would want that) you have the limitation it needs to be in the first bullet of the page. When you have like 15 page-properties this fills up the visible part of a note, scrolling is needed.
To fix that you could create a first bullet like “Metadata for this page” and add the 15 properties in a subbullet but then it are not page-properties anymore!!
This still works when you use a blocks query as we can since a fairly recent release, show the page in a blockquery.
And yes … I would want to see all properties from all blocks when I query a page. But from my testing all properties are alwys shown wether I do a block-query or a page-property so I do not understand you remark about which properties you want to see.
I learned to always use block queries (is the default) and show the pagename as I mostly want to see that. But the different use and naming with almost the same functionality is not right and confusing to me.
1 Like
I fell into this UI-/UX-confusion, and it took me days to realize that I had been using block properties, while believing I was using page properties (and before that, it also took me a week to realize/grok the difference between page-/block-properties).
And then, I had to go back and re-organize/re-edit my pages of notes to adopt this Page Properties stuff.
+1
Depends on what you query.
The purple and yellow outlines show the exact same relationship. (In my opinion anyway)
Therefore the query result is the same. If “block” Article title is returned we have access to the property type:: article and source:: link to artikel (hello autocorrect lol) and not to source:: link to secondary article
When block Article mentions this other article is returned we have access to source:: link to secondary article and not to source:: something else idk
This works the same in both cases.
But anyway… All that aside.
I’ve taken the time to do some queries on the data in the screenshot.
Things I’ve noticed:
- Advanced queries assume pages
I dislike this. - Block content is irrelevant for page properties and thus shows the full block content instead of empty also dislike this.
Conclusion: there is currently no elegant way to combine properties from pages and blocks.
I still want to define front matter. I see value in being able to organize a page with properties. There are just some implementation decisions that don’t make this seamless.
Preferred would be:
- page metadata is its own section, not a block on the page
- just like block properties are not a child block
- page metadata can be collapsed
- page metadata and block metadata can be used interchangeably (if I query for a specific metadata I want all results in a way that makes sense)
Currently I use:
- page properties to define certain things about the page (this is 99% of all properties)
- an article page has a type, creator and source property for example
- block properties for more general things
- I have certain trackers like medicine taken, energy, symptoms etc.
I guess we just disagree on property usage 
1 Like
Thanks for your extensive answer … it is interesting to see the different uses everybody has and how that defines your context in using properties.
In my case 99% of my properties are in fact used as properties although many of them appear in the first bullet so they are in fact technically page-properties.
The block columns is in all queries something I remove immediatly because it is to big a thing to be used most of the time. And I do not use page queries as I don’t need them as properties can do everything. Show pages and blocks depending on what you want.
Disagreeing on the use of properties is fine off course. The only bad thing about it is that you are not totally happy how it is now and neither am I. But I think there is a big split in the community about this so I guess nothing will change which does not help either one of us 
.
Thanks and kind regards, Jeroen
2 Likes
Man I am about to lose my mind. I have been trying so hard to incorporate “Page Properties” to my reading notes pages, so that I can use them for querying and filtering, only to realize that the page properties can also be queried as “Block Properties”.
That is very inconsistent UI, and seems to void @Siferiax 's defending argument in favor of Page Properties that she can use them to query specifically for pages.
Now, I am seeing that the following two queries are basically the same for me, they result in the exactly same table:
{{query (property :status "#to-read")}}
and
{{query (page-property :status "#to-read")}}
I mean, I thought I wouldn’t be able to query the Page Properties from block the queries for Block Properties. Keep in mind that the #to-read is a “Page Property” in my pages. That status:: #to-read stays in the first block of the page material dedicated to my readings.