I looked at the mockup:
- There you propose a single filter-sort-group query, which:
- is a bottom-up approach (hierarchy-wise)
- has no surprises (thus no discoveries either)
- operates like this:
- extracts some items (there books)
- imposes some structure on them, which is:
- regular
- in position: properties have fixed layers
- top nationality, bottom authorship, birthday on authors only
- in participation: e.g. a nation without books doesn’t appear
- in position: properties have fixed layers
- limited
- in size: the exact number of layers is predefined
- in info: the reader should already know what each layer represents
- regular
- This is not a genuine tree.
- unless if we abstract nationality and authorship to e.g. origin
- but then more results may appear and of less rigid structure
- unless if we abstract nationality and authorship to e.g. origin
- In contrast, a genuine tree:
- is a top-down approach (hierarchy-wise)
- operates like this:
- begins from some root
- spreads out in irregular forms
In my approach I implement a generalized graph traversal (like you said on this occasion), fed on every step by multiple predefined parameterized queries, operating on a level above them, to provide an unlimited partial structure of the graph itself, potentially discovering emerged relationships (e.g. “items authored after the birth of nationalities”, which may be books, but not strictly). Therefore, this is more than a tree, it is a cascade. It should still be possible to cover your scenario, but should:
- define some queries that are more targeted, in order to avoid unwanted results
- implement some syntax that needs parsing, e.g.:
{{pagecascade top strict-from nationality ; flat strict-from nationality ; flat strict-from author }}
I’m looking into it.