By simply adding a SuperTag to a tiddler (For example, Task), you will see a form showing in your tiddler (e.g. completed and completeType field editor), see screenshot below:
The field is only shown if your tiddler already had this field. To edit non-existed field that defined by SuperTag, click " ≡ properties" button to expand the available field editor list:
Nice work! That’s a good idea to use jsonschema to a render a form for editing the fields of the current tiddler while in view mode.
I notice your super-tags widget is very opinionated on how it will find the schema. It requires the schema to be stored in the schema field of a tidler which is tagged with $:/SuperTag/TraitTag. The schema tiddlers can’t be used directly and instead another level of tags is required.
This “opinion” is hard-coded in the typescript so it can’t be easily changed.
What do you think about having an attribute on the widget which expects a filter to be given? The output of this filter will be a list of jsonschema which will be used by the widget. If the attribute is not given, then it can default to what your typescript is doing (I think this is equivalent to your code):
That way the user can create their own view template which can trigger on a word in the title or some other condition and the schema can be chosen by means other than the specific tag structure you’ve chosen.
I didn’t figure out this filter expression, the version i wrote was full of bug so i decided use js for this logic. And I thought there can be other widget to run other logics.
Now that you have this working filter expression, I can add it as default filter, and make the only widget customizable, thanks. I will add it in the next release.
Another reason I use js for this, was that I used to try using jsonforms library at the beginning, it supports uiSchema field, so I need to get two fields out of them, which can’t be done by filter expressions easily.
Chat with a friend today, and he introduce Potluck: Dynamic documents as personal software to me, which inspire me that we can write some regex rule or prompt (for GPT), to auto extract tiddler content, and fill into the form provided by supertag.
This is excellent progress towards making TiddlyWiki more proactive and “intelligent”, i.e. a knowledge engine while furthering interoperability between plugins and data. I think the biggest challenge facing us as a community now is agreeing on standard ontologies with which we can reliably design around. I’m working on furthering this idea on my end with working demos, but I strongly urge folks in the community throw some working ideas out there to see if we can make something out of this supertag innovation. Congrats and many thanks once again to @linonetwo for moving us in this direction with working software.
This ties in with my classification of TiddlyWiki as a smart document.
In someway’s with tiddlywiki the PotLuck approach is not new, but they put it so elegantly;
We think a promising workflow is gradual enrichment from docs to apps: starting with regular text documents and incrementally evolving them into interactive software. In this essay, we present a research prototype called Potluck that supports this workflow. Users can create live searches that extract structured information from freeform text, write formulas that compute with that information, and then display the results as dynamic annotations in the original document.
There email; addresses are on that page, has anyone contacted them about TiddlyWiki?
I remember listening to a podcast episode where the creators of potluck talked about their insights from their project. It was quite fascinating and it was strikingly similar what we do everyday in tw5. Don’t know if they’re aware about us, but we definitely should exchange notes with them.
I saw a lot of resonances of that article, when I read it, with TiddlyWiki on one hand and computational notebooks (like the ones from Mathematica, Jupyter, OrgMode, Grafoscopio, Lepiter) on the other (as I said before we’re combining TiddlyWiki with computational notebooks with TiddlyWikiPharo).
This progression from dynamic documents to apps has been explored in several places/times, and from our workshops over here, seems pretty empowering as a way to go from the popular “end user” practice of computing/informatics to “power user” just doing and automatizing the day to day life things and having a better place to do them that word processors, spreadsheets and slide presenters. How this progression is made, is where a system like TW (or Pharo/Smalltalk powered systems) shine, as they blur the distinction between the app and the IDE (which is not so clear in others or even with a pretty big discontinuum). And in such blurring, being meta-systems (made/extensible on themselves) marks a big difference.
The research explorations from Ink and Switch, also with local first software, have a lot of connecting nodes with practices like the ones empowered by TW. For example, TW is a local first portable “cloud document” (if local savers are enabled). Connecting our day to day practices with those more “researchy” explorations seems a way to bridge “explorations in the lab” with “explorations in the wild”.
