Query to format structured blocks into table

Questions & Help Queries
1

I am trying to find a versatile query to transform blocks into tables.
Given the following block structure

#name

  • child-block 1
    • grandhchild-block 1
    • grandchild-block 2
  • child-block 2
    • grandchild block 3
  • child-block3
    • grandchild-block4
      • great-grandchild1
      • greant-grandchild2
    • grandhchild-block5

Can I construct a query that generates a table with the following schema?

table title:#name

child-block1 child-block2 childblock3
grandchild-block1 grandchild-block3 grandchildblock4
- great-grandchild1
- great-grandchild2
granchild-block2 “” grandchild-block5

Essentially

  • the child blocks would be treated as table headers.
  • the grand-child blocks would be treated as values
  • any child below the grand-chilld would be listed as bullet points within the grandchild’s cell

Additionally, if there is a way to append any new properly structured #name block to the table created by the query (instead of having multiple #name tables), that would make for a perfect versatile query to coalesce structured content.

Thank you!

2

Welcome.

  • What you are asking for is a challenge of high difficulty.
    • The transforming expressions of the resulting query would be many more than the querying ones.
  • To attract the few people able to attempt a solution, perhaps you could argue on how that would be actually useful in practice.
    • Maybe by replacing the exercise-like generic description with some real-life example.
    • The thing is that queries in Logseq generally expect structured data in properties rather than in nested blocks.
      • There is a chance that your example could be served by a different structure.
3

Thank you for your feedback @mentaloid

Complexity

I am aware of it and wondered if I should ask for a the simplest version of my request first. A starting point could be to simply be able to transform

title

  • child block1
    • grandchild block1
  • child block2
    • grandchild block2

into

child block2 child block2
grandchild block1 grandchild block2

Usefulness

This query would essentiallty be the complement to templates.

Imagine that you have a template to document your work achievements

#workachievement

  • company
    • value1
  • role
    • value2
  • task
    • value3
  • achievement
    • value4
Company Role Task Achievement
value1 value2 value3 value4

or your mood journal

#mood

  • today I…
    • value1
  • this made me feel…
    • value2
  • the reason is…
    • value 3
Today I… This made me feel… The reason is…
value1 value2 value3

or your project ideas

#projectidea

  • description
    • value1
  • target problem
    • value2
  • expected benefit
    • value 3
  • proposed implementation
    • value 4
Description Target Problem Expected Benefit Proposed Implementation
value1 value2 value3 value4

You could copy paste the query in the #workachievement or #mood or #projectidea pages, and, just by changing the target hashtag, get a summary table that would give you an overview of your notes on the topic. Thinking about it, adding the date of the note could make it even more useful.

Properties

I have seen an example about using properties for a table of film reviews, and I am open to a suggestion that would make use of properties.

The reason why I asked for a query that builds on the basic nested writing structure of Logseq is that

  • there is a clear, almost natural, relationship between a (shallow) nested block and a table. So converting similarly structured blocks in a table sounds to me like a natural extension of grouping blocks that have the same tag
  • Creating properties for each child of each template would lead the a lot of tags that have very little organisational value beyond the creation of the table. Properties are often topic dependent, and a #description pulling blocks from any topic would have little value.
4
  • All the real-life examples that you shared so far are better served by properties.
  • Regarding your concerns:
    • Nested blocks are not as naturally related to tables as it seems on first sight.
      • Nested sibling blocks don’t enforce any particular structure without a template.
        • They can get easily messed up when:
          • the order is modified
          • a block is missing
        • Changes to Logseq templates currently don’t update existing blocks.
          • When this problem appears, it can be too late.
      • A table can be expressed as a nested structure in two ways:
        • rows of cells: this is the typical way, used e.g. in HTML
        • columns of cells: this is your way and seems less natural
      • Though useful, tables are not very natural themselves to begin with.
      • A block holding a single value is kind of a waste.
    • In contrast, a property-oriented template doesn’t create children, but properties within a single block.
      • For some ideas, have a look at Can LogSeq glossaries and abbreviation directories
      • For a more natural way of entering information, consider using Inline properties
      • As a graph gets bigger, filtering becomes increasingly important.
        • Given that a query will be used anyway, properties provide many filtering options that nested blocks cannot.
1 Like