It is different to, but not unlike my current thoughts, as yet unpublished, where we are trying to discover the structure, which can be built as content/data arrives in a wiki. Tolerant of missing information, it discovers and builds what it can from the data available, and could identify what is missing and kindly ask for it.
If I understand correctly your idea is also “discovering something as a result of ‘analysing’ list fields and tiddler existence”, but you seem to go way beyond that.
I can see the creation of some analytic functions here such as
iterate the items in a list field and return a value that determines the ratio of “list items” to “items with actual titles (in the wiki missing or otherwise)” OR the ratio of “list items” to actual existing titles.
Simply returning the number of item in a list
For a given item how often it is named in the same list field throughout the wiki, named in any list field in the wiki
Ratios or values that assist logical determinations resulting in questions like
Would you like to enable virtual nodes for publishers?
And again: Is it fair to say we need these components;
Content definition (what is what and related to what, a schema)
Content display ( display according to the content found and the definition)
Content Editing (Permitting change to content)
Content query reporting/listing
Content analytics that as @Springer suggests can feed back into “Content definition”
[Edit] Post Script
The current development in the preview Tiddlywiki 5.4.0, of the multivalue variables “MVV” will help in this kind of design. eg one can take a list field and store it in a multivalue variable and then make use of it multiple times even in the same filter.
Ultimately it should allow passing lists into filters and functions easier.
However I still have concerns about this MVV implementation falling short of what it could be.
[Edit] Again
It seems there is also a need to support “upfront definitions” we know right away as we build something. for example if we know we want person, organisation and invoice tiddlers then lets allow this to be defined upfront making their use easy, but then assist the evolution of the definition as data becomes available.
I was not clear enough that I was designing the wiki as a platform any D&D player can pick up and use. I want the D&D wiki to be as simple and as easy to use as possible. So consider this as an ease-of-use feature if non-TW experts can simply insert a Skeleton statblock using {{Skeleton}} rather than having to type something more complicated like {{Skeleton||monster}} or <<monster Skeleton>>. The latter case of using a macro is worse from a usability standpoint as a lay-user who does not understand TW5 would begin to wonder in which situation they should they be using curly braces and when they should angle brackets be used.
This is also why I have worked hard to remove the use of macros in my wiki, replacing them with parameterized transclusions. This way, the end-user has one less thing to think about when using the wiki.
Sure, I get what you are saying, but if you look closely at the excise tool in the editor toolbar, or the link button, there are ways to provision even easier tools, than typing special characters and as a result they can be more sophisticated.
I have returned here as I further develop the related concepts, I believe that it may be possible to build a multi-dimensional solution that would allow sophisticated and dynamic ordering for;
This would however involve a unique kind of algorithm with complex outputs, and may be original work.
An example may be something like if the tiddler has both the role of organisation and contact to always list the organisation card first. Because an organisation may have multiple contacts, or additional information, not related to a contact.
Perhaps sorting single instances of a related card at the top, then multiple instances below eg organisation card then related contact cards with same organisation.
Yet I also see how we could now have a “virtual list of roles” that is populated using a number of filters, such as a filter for each role. Each can be unique to that role. We can use multi-valued variables, Then once we have a list of roles we can apply a sophisticated sorting mechanism, pulling variables from the tiddler in question, or the role tiddlers etc…
Note this is different to the current view template cascade with results in a single view template rather than multiple sorted cards.
For now I am keeping this independent of the viewTemplate cascade but it could be incorporated at a future date.
ChatGPT is helpful here, but I won’t prejudice possible ideas here before I hear your ideas.
It’s different from the cascade, but not so different from having many things (whether or not they’re “cards”) tagged with $:/tags/ViewTemplate — each of which appears only conditionally based on whether conditions (such as role conditions) are satisfied.
Increasingly this (i.e., use of multiple conditional-governed view templates) is my approach, as the idea of a single tiddler “body” is a poor fit for relationally-complex projects…
On a practical note, I also often find that troubleshooting cascade-based body templates is more awkward than working with the older view template mechanism, because the cascade process has so many “moving parts”. With a view template (even if it’s usually silent because conditions aren’t met), the only thing that often needs a tweak when I move it between projects or disable/enable the tag (etc.), is the order of appearance. Much easier to troubleshoot that than “Not seeing what I expected… Hm…. So, is it because (1) the cascade condition is missing (2) the ranking-order for the cascade condition needs adjustment, or (3) the template itself is absent or improperly framed…
I agree but through this card mechanism we can add behaviours such as delist, special ordering logic and more without disrupting imported solutions that don’t know about this.
I still maintain the value of the $:/tags/ViewTemplate
Agreed hence this card approach, and the possibility of adding advanced relationally-complex supportive features
That can be true, but now we can add tools to support the maintenance because with a cards solution we need not be so tightly bound to legacy methods.
Approach
Introduce mechanisms that support the ability for tiddlers to have many simultaneous roles.
other notes
My prior reply above to find solutions in this multi-role approach is a design exploration and we need not concern ourself whether this would be added to the view template, view cascade or independent cards model.
Even this Topic is all about how do we make inroads to complex solutions.
Oh, looks intriguing! I probably won’t be upgrading to 5.4.x until May or June (given work pressures), but I’m looking forward to checking out this plugin from @pmario once I do!
Yes, if you go to his demo page the tool is installed, and it can be used to research standard tiddlywiki components on 5.4.0 and follow the path, much if witch will be the same as 5.3.8
