Yes that should be possible. There is recursive search capability.
Here’s an example related to tasks:
So that would also be a solution for me I think 
Define an index as
- [[cycling]]
- [[road bike]]
- [[electric bike]]
- [[city bike]]
And then query for all references to pages based on child block below cycling in the index.
It is a little inconvenient I must admit.
Old where for my queries:
[?r :block/name ?current]
[?b :block/refs ?r]
[?b :block/page ?p]
[?p :block/journal? true]
New where:
[?v :block/name ?current]
[?h :block/name "hobby"]
[?i :block/page ?h]
[?i :block/refs ?v]
[?c :block/parent ?i]
[?c :block/refs ?r]
[?b :block/refs ?r]
[?b :block/page ?p]
[?p :block/journal? true]
I’m now using the Hobby page for the index only, instead of having other info there as well. That would make the where even bigger lol.
Further edit, as I’m experimenting, here’s the above where, but for the use of properties. (I figured out how to actually use the property value, still dislike it)
[?g :block/name ?current]
[?g :block/original-name ?naam]
[?r :block/properties ?prop]
[(get ?prop :groep) ?groep]
[(contains? ?groep ?naam)]
[?b :block/refs ?r]
[?b :block/page ?p]
[?p :block/journal? true]
I feel like I have completely butchered my graph at this point in time lol. I do like the experiment and ideas though.
The only thing I see against the use of properties is that one would need files for all pages. Most of those files only have a properties blocks. This feels like a lot of overhead. I just need to tag blocks with an activity and the activity itself doesn’t necessarily need a page.
Using namespaces I would only have need of a page for the group to bundle my queries on.
However using indexes I actually only need Hobby to be a page and can put the queries for each Hobby there.
I notice this is giving me quite some things to ponder about 