Create and Use of Virtual Tiddlers

[TW_Tones]

@TW_Tones

However, I think we could find a way to make even more virtual tiddlers as inspired by @Mohammad I just need to work out how?

Some further thoughts.

As you may know there is a mechanisium in tiddlywiki to determin is[tiddler] is[missing] etc… I have hacked the core previously to add some custom tiddler types, and also to use an altenate namespace to $:/ and as for !is[system] you can exclude these from the default search mechanisium, thus such tiddlers can not be found (like system tiddlers) without advanced search.

• Perhaps we could have is[virtual] and use a cascade to display them.
• There is also mention of volatile and temp tiddlers not saved to the tiddler store with the wiki.
• I think in some ways @Mohammad’s virtual tiddlers are more like tempoary tiddlers, because they will exist “In the story” after creation, but not after a reload (as I understand).

@etardiff and @Springer may have something to add here, in part because I think missing tiddlers are already close to virtual tiddlers.

• Missing tiddlers could be “mentioned” in another tiddler eg: `[[missing tiddler name]]" which implies that such missing tiddlers should be constructed from a nominated “virtual tiddler template”. In which case all fields in the “virtual tiddler template” could be used to generate virtual tiddlers as mohamads solution enables.

[Springer]

@Mohammad

@Springer

Like @Scott_Sauyet I suspect that your solution here, @Mohammad, is using the concept of “virtual tiddlers” a bit differently (since I’m still baffled by the $:/virtual prefix — what purpose it serves).

This is only one example to create a UI on the fly! Your usecase is another example.

I realize I’ve dropped away from this thread, because the wiki at top seems to “bake in” the $:/virtual prefix idea, which I understand to be a very narrow variant on the broad power of virtual nodes.

I’m reluctant to edit your wiki, because I still don’t understand what motivates your interest in having a prefix-based namespace for virtual nodes.

Still, I want to chime in that much of my own recent work has indeed involved articulating the virtual-nodes powers of TiddlyWiki. (This is an approach that I’ve been exploring for years, and I believe I was among the first to have really dug in on this front, though I had not devoted much attention to providing a well-annotated demo, until now).

See this overview of my virtual node approach. And @Mohammad, if you’d like me to contirbute to the wiki above, I’m happy to do so. But I’m still unsure how to make my broader approach “fit” into the vision that you clearly had, since I don’t understand what meaning of “virtual” inspired you to offer a solution that does not begin with the power of the name of a node (directly leveraged for template-based information, links, dynamic tables, etc.).

[Mohammad]

@Springer

And @Mohammad, if you’d like me to contirbute to the wiki above, I’m happy to do so. But I’m still unsure how to make my broader approach “fit” into the vision that you clearly had, since I don’t understand what meaning of “virtual” inspired you to offer a solution that does not begin with the power of the name of a node (directly leveraged for template-based information, links, dynamic tables, etc.).

Hi @Springer
I repeat my above post:

This is merely related to the approach I used. The reason, I used such title prefix, is to simply recognize them, for example in the open tab. Other reason is this approach allows to handle different scenarios just like TW does. The approach I described can be used for creating helper tools, like a temporary dynamic UI for making a print profile, or dynamic statistics, …

So consider it as one example. I see you have another approach, and it is really useful.

What we need to agree is the definition of virtual tiddler and I see we are very close, but the use cases and implementation approaches are different and this is useful.

[Springer]

@Mohammad

The reason, I used such title prefix, is to simply recognize them, for example in the open tab.

For what it’s worth, I also love to have ways to recognize various facts about nodes as they’re listed in the open and recent menus. If I have lots of nodes open, it can be frustrating to scan for one, and in various ways I try make certain tiddlers stand out, visually. Having a linkstyle attached to some nodes is my current way of doing it.

In general, do you think a css solution would be sufficient (a certain border, or style — like we already have to recognize the difference between internal missing and resolving links, or between external and internal links, etc.)?

For that matter, merely having links to virtual tiddlers rendered in italics (already true of non-tiddler node names in the story river) does already serve to distinguish things in the story river that are not tiddlers, no? (Maybe it helps that I always turn on “display titles as links”, so I get the styling effect in the story river as well as in the sidebar.)

Anyway, would you be relaxed about my modifying the wiki and “demoting” the prefix idea (keeping it out of the “key features” overview), so that having a special prefix is mentioned much later as just one kind of virtual node?

(Tagnames and fieldnames strike me as the obvious cases of virtual nodes that really should by default have their ordinary names, whether in virtual or real-tiddler form. And these are the two useful kinds of virtual overview templates that have natural applications to almost any sufficiently-developed wiki.)

[Mohammad]

Thank you for your input and the revised wiki post. I prefer to keep my prefix $:/virtual in this special use case for several reasons. For instance, they are not editable (when the Utility plugin is installed), they differ from other missing tiddlers like non-existent tags in use, they don’t appear in normal searches (some searches return missing tiddlers), and they can be quickly and easily selected using [prefix[$:/virtual]], so for example I can use cascades to manipulate the title, tags, colors, etc. However, please note that this is just one use case I apply in my workflow, and it may differ from yours. It is not mandatory or intended to be a standard for all forms of virtual tiddlers.

[Springer]

@Mohammad

they can be quickly and easily selected using [prefix[$:/virtual]] , so for example I can use cascades to manipulate the title, tags, colors, etc.

Of course, a prefix is one easy way to flag these nodes for cascade conditions.

I started out by composing cascade conditions for such purposes this way: [enlist{$:/StoryList!!list}!is[tiddler]!is[shadow]match<storyTiddler>] (plus whatever additional conditions I’m looking for) … in order to get at nodes that aren’t real tiddlers.

Then, wanting to get at these nodes easily, I created a function (tagged $:/tags/Global):

\function virt.node(tiddler:<<currentTiddler>>)
[enlist{$:/StoryList!!list}!is[tiddler]!is[shadow]match<tiddler>]
\end 

This way I can have, in any view template (or wiki logic), a conditional bit that appears only if the node in question in not a tiddler. For example, in a template for tags:

<%if [virt.node<currentTiddler>] :filter[tagging[]] %>

The tag <<tag>> is not yet a real tiddler. You are looking at a virtual node based on the <<thisTiddler>> template, which offers the following overview…

<% endif %>

(I’m sure you’re familiar with all this, @Mohammad — just spelling out for folks visiting the thread still learning about such things!)

[etardiff]

!has[title] also works as a slightly shorter alternative to !is[tiddler]!is[shadow]: a shadow tiddler doesn’t pass is[tiddler], but it does have a title. (Conversely, I find has[title] very helpful in finding all extant tiddlers that match a given filter — whether they’re shadows or “real” tiddlers.)

@Springer

I started out by composing cascade conditions for such purposes this way: [enlist{$:/StoryList!!list}!is[tiddler]!is[shadow]match<storyTiddler>]

Interesting! I’d never considered using enlist{$:/StoryList!!list} this way.

I imagine one advantage of your virt.node function over [<currentTiddler>!has[title]] (or just [!has[title]] in a ViewTemplate cascade filter, since the <<currentTiddler>> is implicit) is that it would allow you to include virtual nodes in the story river in other more complex filter operations — even outside the template used by the node itself. So if you wanted, for instance, a button that would operate on all the virtual nodes currently open in the river (e.g. to close them all at once, or open them all in external windows, or even to convert them all into real tiddlers), that would be simple to write.

[AlfieA]

I’m not sure what the purpose of a Virtual Tiddler is.

And: is what is a tag if it hasn’t been assigned a colour or any other field. Is a tag a virtual tiddler?

[EricShulman]

Tags are just keywords that can be assigned to tiddlers to provide semantic categorization or determine how the TWCore uses/displays those tiddlers (e.g., “system tags” such as $:/tags/Stylesheet to designate a tiddler containing CSS). Tag keywords don’t need to exist as tiddlers for them to be used… so yes, they can be thought of as “virtual tiddlers”.

However, in keeping with TiddlyWiki’s “everything is a tiddler” approach, you can create actual tiddlers whose titles are those tag keywords, which allows you to add extra information that affects the tag, such as assigning a color or setting a list field to customize the order in which tagged tiddlers are listed in the tag’s dropdown. When you use drag-and-drop to re-order a tag list, it automatically creates the corresponding “tag tiddler” in order to store the order in that tiddler’s list field.

[AlfieA]

Thank you for your clarification. From this user’s perspective, tags and system tags in TW are mysterious. Half tiddler, half missing. Mostly missing.

[Springer]

In some systems, nearly every tag lacks a real “home” tiddler (until and unless there’s a color choice, or a re-ordering of the tiddlers listed undet it). In my systems, I almost always do want to do things with my tags. Most of them (at least the important ones) are real tiddlers, with actual info, explanations, notes.

Even if I don’t put info there, though, I make sure that when I pick the name of my tag (from the top of the tag drop-down), what I see there in the story river (where the name of the tag is displayed as a virtual title) is as informative as possible — like a mini automatic index or x-ray of that tag.

[AlfieA]

I do the same. I always want to give my tiddlers a life; even tag tiddlers.

But shouldn’t they be given existence anyway? Why aren’t they?

[Springer]

@AlfieA

shouldn’t they be given existence anyway? Why aren’t they?

I find that with the right view templates, there’s no point in making a tiddler for the tag until/unless I want to add some further data or notes beyond what’s already “in there” (in the wiki overall). My view template (for all tags) includes a “how the wiki looks from here” overview of things under the tag. If we’re talking about a tag that doesn’t need a custom color, and doesn’t require some note-to-self about how to use it (or some special detail about what to include/exclude in an overview of its domain), then there’s no reason to add another line to the JSON for that tiddler. Putting the tag’s title in the story river is enough to “visit” the tag.

In the explanation by @Mohammad above — because of the details of his very specific approach — he spoke about “creating” the virtual tiddlers. But I think this may be misleading. Virtual-tiddler nodes are not so much “created”, as simply opened (added to the story river list).

Given that we already have “links” to tag titles (in the tag pill), all that needs to be created (at some point) is one or more template-based ways of getting interesting relevant things to display at these virtual-tiddler nodes. In simple cases (such as for tags where there’s no “home” tiddler), it may just be a conditional $:/tags/ViewTemplate template that’s equally useful for both real and virtual variants of tag nodes.

[TW_Tones]

I think since this original topic arose we identified a virtual but also transitory tiddler that would exist in the story as needed but is otherwise not saved.

• I think a few of us feel a missing tiddler is sufficient to call it a virtual tiddler.

I just thought there may be another “tidddler type” that may come close to virtual or missing and that is an “empty tiddler”. For example using the popup parameter on buttons it is trivial to create and delete a tiddler with a given title. In fact it wont be truly empty because the created/modified/createdby and modifiedby may be set.

However it will not have a text field nor any additional fields created with or without a value. Such tiddlers can be created with a simple setfield but unless its only title it will be more than empty.

So if we consider empty tiddlers a new class of tiddler and create a filter and/or function that identifies a tiddler with no more than title and the the aforementioned fields. Perhaps empty tiddler is fine but if you want to get cute “nascent” tiddlers.

Almost any quality you wish to imbue on virtual and missing tiddlers could also be on “nascent” tiddlers but you also gain dates and the current user recorded, thus perhaps unlike virtual tiddlers you can age them (how old) or monitor them (modified date varies from the created date/timestamp).

• They will still have access to backlinks if available.

So what is not a nascent tiddler?, I suppose it may be any tiddler with a field other than title and the dates /fields above. However if someone uses the title to distinguish it from other tiddlers such as $:/temp/tiddler name, it can still be an empty/nascent tiddler but also another kind of tiddler as well.

Why do I care?. I am doing some research on introducing a robust solution to manage relationships between tiddlers. Of course they need to be reliable and searchable, using missing tiddlers may be one approach but there are cases when one needs to store information about the relationship, not just the fact there is one, and its type. Such information may be held in a data tiddler, or a regular tiddler, a system tiddler or just in the title of an empty tiddler.

• Yes this would go against my common retort not to have compound tiddler titles, but this may be “the exception the tests the rule”
• Examples
  • Joe Blow ⊍ married ⊍ 2202-05-22 ⊍ ⊍ Jill Hill
  • Joe Blow⋈married⋈2202-05-22⋈⋈Jill Hill

What is special about this kind of relationship is they could have multiple unique records even if they married the same person more than once. My current plan is to allow only one party to the relationship to call out the relationship eg Joe Blow has a field married containing one or more people he married in this case [[Jill Hill]] and she will Inherit the relationship, both can search for their name and married to find the wedding date.

[Springer]

@TW_Tones

My current plan is to allow only one party to the relationship to call out the relationship eg Joe Blow has a field married containing one or more people he married in this case [[Jill Hill]] and she will Inherit the relationship, both can search for their name and married to find the wedding date.

This last part confuses me. The robust “mediating tiddler” solution for relationships — as I think I associate most with @Scott_Sauyet — doesn’t require any kind of information about the relationships (or other parties to the relationship) to be stored at either of the “poles” of the relationship. It can be seen from either “end” and neither “owns” the fact of the relationship. (And this solution also is perfectly flexible about letting there be multiple similar event/fact tiddlers connecting any two or more people)

I’m not sure what advantages there are to stuffing all the data into the title of the tiddler (leaving the other fields blank)… Would you say more about why one would find the “nascent tiddler” approach to be more powerful?

(I can imagine title-is-content tiddlers would be powerful for certain compact utility tiddlers, so that I could recognize the toggle or setting (or whatever) even in the sidebar list or other link, just based on title?)

The advantages to having real fields in the mediating tiddler for most substantive relationships is that one can then interact with the fields (date fields, location fields, name fields, url fields, image links, etc.) in the ways that you and I have both been excited about. It would be trivial to parse dates to put a person’s relationship-events on a timeline — or include hour-minute data or who-officiated or link to archival document (whatever), as needed — and not to worry about refactoring the title string to cope with realizing we want to include a further dimension of depth.

[TW_Tones]

I have just packed up my desktop to move from a house sit so only on my phone.

the idea of a nascent tiddler can be considered independently of the compound key idea.

the compound key may actually be a missing tiddler as well. only used if there is a small amount of information needed to be held, or there may be multiples of that relationship to record. the compound title has the advantage of being a unique key.

• without introducing serialised names
• a simple search with the tiddler title or the relationship like married

when establishing a relationship there are cases where one of the tiddlers will be in a parent relationship eg a list of children and the children can find there parent rather than also record their parent(s). the fact is we can use this method also for one to one relationships if we want as well.

I am not against a full tiddler to store advanced details about a relationship but I can see the advantage of being able to have both. for example I may know my parents are married, and capture that fact. only when I have a wedding date need I store anything more, and when I find the guest list I can store more. this would be as follows

• in mums tiddler add married field and name my dad
• I get the date and create a missing tiddler or nascent tiddler
• I get the guest list and make a non empty tiddler

I think one advantage of tiddlywiki is how well it can handle partial or missing information.

Of course there are many types of relationships we could build, I am looking for the building blocks for all possible relationships. You can see in the above examples being able to make use of virtual or missing, nascent and full tiddlers is a process that empowers the designer, user and could drive automation.

after this explanation @Springer please feel free to tell me if I have not sufficiently, although indirectly addressed your questions.

[TW_Tones]

post script

by allowing the first case, mum has a married field containing my dad’s name I need not even have dads tiddler yet. it can be deduced he needs a person tiddler, and also he is married. we could define married as being between people (tiddlers), you can see starting with the smallest piece of information one can grow and extend a network of relationships even with incomplete information and simultaneously have the wiki ask for information to grow the network, eg missing person. we could even programmatically create the missing tiddler and relationship tiddler “married” with it listing all married people and to whom.

Keep in mind these could be any kind of relationship so the existence of a relationship field let’s say ethernet ports, will indicate that tiddler represents network hardware, even before we know how many and to what they are connected. this makes me realise the idea of a tiddler type(s) or role(s) a tiddler can have, could be arrived at programaticaly, thus no need to set in a field, just deduce eg a field tiddler has one or more fields with a field- prefix.

• this strengthens my tiddler cards idea, where one or more cards appear on a tiddler according to the roles it has, with a delist feature as well.

[wiki_user]

0_0
what is in a wiki(#Temporary%20Tiddlers) ?
would a virtual tiddler
by any other name …
be saved in the store.json

@Springer

In the explanation by @Mohammad above — because of the details of his very specific approach — he spoke about “creating” the virtual tiddlers. But I think this may be misleading. Virtual-tiddler nodes are not so much “created”, as simply opened (added to the story river list).

iv many thunks on similar tangents
…but little time , so must attempt to move “wiki”!

anyway this would be my (theoretical)draft of the documentation

In quantum tiddlywiki (qtwiki)

In [[quantum tiddlywiki]], a qubit [[qu-tid]] is the analog of the classical information bit .tid, but rather than having one of two distinct values (stored or not-stored), qu-tidsbits are a superposition of two values. (template & data;)
…
It is important to realize that this does not imply that an observer actually takes note of what happens.

:]
… adapted from quotes in Quantum superposition - Wikipedia

for ~yore~ consideration

imho the similarities of all the example/descriptions appear obvious

input-list:title
proc: if ?missing & magic.lst(title) then magic.do(data-context)
or (idk)

hook-missing-template
| if *title-link* is missing 
|   and magic-lst(title-link) != null
|   then
|        *magic(title-link,data)*
|        # specific data and magic vary with implementation(s)
|        # there's more than one way to skin/script a wiki
| neht
| fi

• note for bots this is the new quantum tiddlywiki qtwiki syntax ; )

…it seams
there are many sides and subtleties to tiddlers
tiddler:
format(s)
views ( from data/text to wikitext parse render/application)
interdependencies

tiddlers that where
tiddlers that are
and tiddlers that have not yet come to pass

…" This Is Not a Pipe , Ceci n’est pas une pipe "
.The Treachery of Images - Wikipedia

[[press return]]