Thanks everyone for your useful contributions. As I'm understanding, in TW users can set up forms of static or dynamic inheritance within WikiText and field values, while field keys, tiddlers titles and tags can only be inherited statically (for static inheritance I'd mean the information is copied into the new tiddler once at its creation, for dynamic inheritance I mean that the information is displayed through a reference)
As a relatively new user I'm finding unconvenient having to rely this much on static inheritance. Not having defined naming conventions yet, I have the need to change things often along the way, and I must do this manually. Even with something like Tiddler Commander, for me this kind of maintenance is currently being a major pain in using TW. Actually, I'd value the freedom coming from a knowledge base system which can easily (re)adapt to my always-changing mindset, instead of being forced to build an (incomplete) mindset in advance and being stuck with it. For this reasons I wish that field keys, tiddlers titles and tags would be dynamically inheritable. On Thursday, May 13, 2021 at 1:51:32 AM UTC+2 TW Tones wrote: > Folks, > > My thoughts without working through all your comments (yet) > > Inheritance is a concept, there are many ways to implement it, you do not > need core changes, Inheritance can just be at creation, a smart new hear > button will create a child from values in the parent, templates for new > tiddler is also in effect one level of inheritance. Solutions where a set > of values defines a "context" eg; work, project-name, client; allows new > tiddlers to inherit a prior value. With this approach the relink plugin can > be configured to support renames. > > Now in these cases inheritance takes place in each node at creation or > update. Using the KIN operator gives you access to the whole inheritance > tree. > > Now if you wanted to determine inheritance without actual values in each > tiddler you need to use a search/kin filter to find the value for each > tiddler, every time you want that value. I am sure it can be done but I > question the value. There may be some rare cases where it is a good > approach, but more effectively if limited to particular fields and > tiddlers, rather than weighing the wiki down with more calculations. The > exception may be if you only need to inherit from a parent not deeper. > > Another way to represent inheritance is rather than provide a field with a > value, provide it with the code or filter necessary to find the value. If > it contains a filter or macro use that to find the value otherwise use the > actual value in a field. for example a field could contain a filter using > the kin operator to find the value. > > If you do not need to explore multiple levels to find the inherited > values, and can quickly identify from where to inherit the value > performance would be greatly improved. > > Regards > Tones > > On Thursday, 13 May 2021 at 09:25:39 UTC+10 Soren Bjornstad wrote: > >> I'm with PMario – I'm just not sure that this makes much sense in the >> TiddlyWiki idiom. It's like you're used to driving a car, and TiddlyWiki is >> a train, and looking at the train, you go, “But where are the rubber >> tires?” It just doesn't have rubber tires...but it still rolls just as >> well, it just works a different way. TiddlyWiki is almost completely >> non-hierarchical, so inheritance seems like a particularly bad fit. >> >> > I also found Trilium's attributes extra functionalities very useful, >> esp the ability to use them to define custom relations between different >> Notes, which is similar to what tiddlymap does but has several advantages, >> e.g. to query Notes based on their relations. >> >> If I'm understanding the ability to "query Notes based on their >> relations" correctly, this works exactly the same way in TW...just put the >> name of another tiddler or tiddlers in a field, and then use a filter. >> E.g., for a parent/child relationship where the child stores its parent in >> a 'parent' field: >> >> [parent[MyTiddler]] – finds all children of MyTiddler >> [parent[MyTiddler]related[MyOtherTiddler]tag[Source]] – finds all sources >> that are children of MyTiddler and related to MyOtherTiddler >> [tag[Source]parent[MyTiddler]links[]] – finds all notes linked to by >> sources that are children of MyTiddler >> >> (If you want to allow more than one tiddler to be in the field for >> relations, you would make the field contain a title list >> <https://tiddlywiki.com/#Title%20List> and use 'contains:parent` instead >> of just 'parent'.) >> >> For standard inheritance, in TW you would normally just compose your >> filter to look for the parent tiddlers when determining what value a field >> has. I would probably need an example of how you use this to avoid giving >> you something really convoluted, so I'll pass on trying to provide one up >> front, but if there's something you're looking for let me know. >> >> For copy inheritance, as PMario mentioned, you would create a custom >> button on the parent tiddler (or anywhere else you like) that prepopulates >> the fields. In fact this is more flexible because you can set the fields to >> whatever you like. For example, here's a button that would copy the tags >> and description of the current tiddler to the newly created tiddler, set >> the `year` field to the current year, and set the `url` field to the >> contents of some configured tiddler containing a base URL plus the title of >> the current tiddler. >> >> <$button> >> <$action-sendmessage >> $message="tm-new-tiddler" >> title="New Child" >> tags={{!!tags}} >> description={{!!description}} >> url={{{ [{MyBaseUrl}addsuffix<title>] }}} >> year=<<now "YYYY">> /> >> New Child >> </$button> >> On Wednesday, May 12, 2021 at 2:59:45 PM UTC-5 damscal wrote: >> >>> Hi Mario, thank you for your reply- >>> I haven't thoroughly thought about the possible implementations in TW, >>> but I've found Trilium's approach very intuitive and efficient to work >>> with. I guess a similar approach, being able to dynamically inherit tags >>> and other fields using template tiddlers, would make TW quicker and easier >>> to manage, esp if the user hasn't a well defined mindset yet and need to >>> change things all the time. Arguably I would guess it could actually be >>> coherent to the philosophy of tiddlers ( >>> https://tiddlywiki.com/#Philosophy%20of%20Tiddlers ), and perhaps a new >>> exporting option could be added that would let the user choose whether to >>> export tiddlers as they are, or to copy the inherited referenced >>> information into the tiddlers that are being exported in order to make them >>> self-consistent (kind of the analogue of copying symlinks targets or the >>> symlink themselves when working with filesystems) >>> >>> it could be off-topic, but incidentally I also found Trilium's >>> attributes extra functionalities very useful, esp the ability to use them >>> to define custom relations between different Notes, which is similar to >>> what tiddlymap does but has several advantages, e.g. to query Notes based >>> on their relations. >>> On Wednesday, May 12, 2021 at 8:12:03 PM UTC+2 PMario wrote: >>> >>>> On Wednesday, May 12, 2021 at 6:42:35 PM UTC+2 damscal wrote: >>>> >>>>> Trilium <https://github.com/zadam/trilium> provides quite intuitive >>>>> built-in ways to have Notes (the analogues to Tiddlywiki's tiddlers) >>>>> dynamically and selectively inherit their Attributes from other Notes, as >>>>> described here >>>>> <https://github.com/zadam/trilium/wiki/Attribute-inheritance> and here >>>>> <https://github.com/zadam/trilium/wiki/Template>. In Trilium, >>>>> Attributes <https://github.com/zadam/trilium/wiki/Attributes> are >>>>> similar to Tiddlywiki's fields with extra built-in features. >>>>> Inheritance is convenient as it saves a lot of time when creating and >>>>> organizing notes, plus it makes maintenance very straightforward. >>>>> >>>>> Can/could Tiddlywiki achieve something similar? >>>>> >>>> >>>> Sure, if someone would program it. ... BUT there is absolutely no >>>> support in the core atm. So nothing will work. Especially filtering would >>>> have a big problem. >>>> >>>> TLDR; >>>> IMO you should probably tell us, what exactly you want to inherit, so >>>> we can tell you how to implement it in "the TW way", which will be more >>>> efficient in the long run. >>>> >>>> ------------------------ >>>> >>>> From your links, it seems some "attributes" are "indirectly" inherited. >>>> eg: >>>> >>>> parent has (key-a: value-a) >>>> | >>>> +-- child 1 .. will inherit (key-a: value-a) from parent >>>> +-- child 2 .. will inherit (key-a: value-a) from parent >>>> >>>> If child 2 is moved to >>>> test has (key-b: value-b) >>>> | >>>> +-- child 2 .. will inherit (key-b: value-b) from test >>>> >>>> This behaviour can have some "nice" effects, if you know, that they >>>> exist. ... BUT it also "connects" 2 elements in a way, that they only can >>>> exist together without loosing information. ... That's not how TW is >>>> designed. >>>> >>>> In TiddlyWiki, "a tiddler is a tiddler is a tiddler". ... So they >>>> should be usable, even if used or moved as a single unit. >>>> >>>> We do have other mechanisms, that let us "connect" 2 tiddlers. .. Tags, >>>> New Here, New Journal here, links and transclusions ... >>>> >>>> Tags are like "groups" >>>> >>>> New xxx ... Some fields from a "template" tiddler are copied over to >>>> the new tiddler. ... This can be changed, if you create your own buttons. >>>> >>>> [[links]] ... Are handled by the core in a special way, so showing >>>> "backlinks" can be fast. >>>> >>>> {{transclusions}} ... connect 2 tiddlers in an "indirect" way. ... So >>>> they can live alone, but they are not "complete" if they are alone. >>>> >>>> -mario >>>> >>>> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3e8776cc-9e9b-4d1f-ba9d-28591be10f33n%40googlegroups.com.