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.
- Page properties are always block properties. Block properties are not always page properties
- What I was saying is the reverse.
When querying specifically for pages, you will only see page properties in the resulting table.
As in I want page X, not I want property X.
Use case example: all pages within a specific namespace.
When you query based on properties it doesn’t matter.
The only thing that’s different is the resulting table. It either has or doesn’t have a block column.
- Which if the property is exclusively a page property is useless.
- Which if the property is exclusively a block property is useful (shows title of the block)
- Which if the property is both becomes a good old mess!!
That last point is why I had to resort to using status:: research exclusively in blocks and just have the block title be a page reference if there is a specific page I need to research further.
It was… Frustrating
It would look like this essentially:
So removing block column removes the nice title and removing page column removes the proper page name. Two things I need to see.
And for the other the reverse is true, it would remove status:: research and journal page name. Two things I don’t want to see.
Aka you can’t win when you mix them.
I think that’s the main problem. And my conclusion in my previous post.
Hi All, the page-property does not work when having more than 2 values for it.
eg: setup a page-1 as follow:
custom-property:: logseq, properties
Then , setup another page with following query:
{{query (page-property custom-property logseq) }}
This shows 0 pages.
Same issue with block properties. Having more than 1 comma separated value filters it completely.
You need to use references:
key:: [[value 1]] [[value 2]]
1 Like
- There are 2 parent blocks with 2 child blocks each.
- When I query to get a particular parent block with properties from child blocks - it shows “no matched results”
WHY? Is there any mistake in the query or in the settings?
PS: Pages and Blocks both are enabled in query settings.
Blocks
Query
{{query (and (property :amendment-in [[Central Goods and Services Tax Act, 2017 (CGST Act)/SCHEDULE I]]) (property :para “4”) (property :effective-period “Jul 1st, 2017 to Jan 31st, 2019”))}}
Query Settings
So that’s not how queries work actually.
As shown at the start of my post:
We don’t have access to properties defined in child blocks.
The query you posted would ask in plain English:
- Give me the block that
- has the property amendment-in with value Central Goods and Services Tax Act, 2017 (CGST Act)/SCHEDULE I
- and has the property para with value 4
- and has the property effective-period with value Jul 1st, 2017 to Jan 31st, 2019
There is no such block in your data and so your query returns nothing.
Your exact question can only be solved with advanced queries and would be something like this.
- Give me the parent block that
- has a child block with
- the property amendment-in with value Central Goods and Services Tax Act, 2017 (CGST Act)/SCHEDULE I
- and the property para with value 4
- and a child block with
- the property effective-period with value Jul 1st, 2017 to Jan 31st, 2019
- has a child block with
1 Like
But, when the query is set to call:
Give me the block that has
- the property amendment-in with value Central Goods and Services Tax Act, 2017 (CGST Act)/SCHEDULE I
AND - the property para with value 4
=> It returns the parent block (even when the properties set in its 1st child block).
The issue only arrises when we call a parent block by quering properties from multiple child blocks (and not only from first child block).
This is a false observation probably.
The blue arrow in the screenshot is the query result. The red arrow is the breadcrumbs the query will show with the result.
If we outdent the child block, it looks like this:
If we were to make a child block beneath it, we see what an actual parent - child relationship looks like as a query result:
Hopefully this will help clear up some things.
1 Like
FOA, thank you for explaining in such detail.
But still unable to understand that when we are able to call a child with its properties then why can’t we use AND operator (in the query) to call 2 childs as a result and then the breadcrumbs will be that parent block.
1 Like
- Because it isn’t
- I want to get child a AND child b
- Instead it is
- I want to get all the blocks that match condition a AND condition b
- and the query then returns all those blocks
- it will display not the parent specifically, but the breadcrumbs leading to that block.
To illustrate that last point:
(Yeah I’m on my phone now lol)
1 Like
Wonderful, now understood. How foolish I talked. 
My query is asking to give birth to a new child block by combining 2 child blocks and that’s not possible and I am assuing that breadcrumbs as that new child. That’s why you mentioned “There is no such block in your data and so your query returns nothing.”
So, technically logseq query understands everything as a block and didn’t differentiate between parent block and child block.
Also, to get multiple child blocks in result, we should use OR operator instead.
Thanks!! 
3 Likes