Thanks Charlie, But thanks to your inspiration for raising the the "conceptual issue", in a way it allowed me to state my thinking on the subject.
Ideas, I feel I have failed to express so far. Tones On Tuesday, 5 October 2021 at 13:50:57 UTC+11 [email protected] wrote: > Crap. Forgot to say: your post is a damned fine contribution to the > knowledge base. > > On Monday, October 4, 2021 at 9:13:29 PM UTC-3 TW Tones wrote: > >> Charlie, >> >> There is in fact a middle way between structured and unstructured. An >> example would be if you were building a contact database and when it came >> to meeting extended family at holiday times and asked them for their phone >> number, you also noted down their parents names. You could even record >> there children's names and more but if you only recorded their parents >> names this would be fine. What then happens is over time as you speak to >> each member of the family and get their parents name the family tree >> hierarchy simply "emerges" from the details. >> >> You can see here that in the above example we have established that a >> hierarchy exists in the real world and ensure we simply collect enough >> information each time we talk to someone "Their parents" that the hierarchy >> builds over time. Such hierarchies need to tolerate missing information, >> but they can actually help us discover what information is missing, Which >> we can then seek. >> >> There are plenty of hierarchies that exist in the real world that almost >> need not be stated like family trees and >> earth > Country > state > county > town > street > number >> If one assumes these exist in the first place, it informs us of what it >> takes to get a full address, but a fuzzy hierarchy and tolerance for >> missing information. for example you may only record a state/town for where >> a cousin lives, you can assume the planet, country and county and perhaps >> for now live without knowing street and number. >> >> The thing is by being aware of hierarchies that exist or you discover, >> and accounting for there existence, but not "slavishly" trying to build >> them, these hierarchies' just emerge from the shadows over time. In many >> ways this helps the unstructured data trend towards more complete >> information over time. >> >> To me this is where an unstructured database can exist, in such a way >> that overtime, the obvious, but even hidden structures start to emerge. And >> you see here there is not problem having both at once. In fact within our >> unstructured database there will be other emerging structures like lists, >> tables, networks and common attributes or values. For example, if someone >> has the "same home phone number" (land line) as another person, perhaps >> they live at the same address? We may learn they live together, even >> although we don't have their address (however we have the phone number >> which we can and ask for the address). >> >> This ability for tiddlywiki to accommodate the unstructured through to >> multiple and incomplete structures is, I believe, one of tiddlywiki's key >> attributes that can empower its application universally. >> >> Regards >> Tones >> >> On Saturday, 2 October 2021 at 00:34:22 UTC+10 [email protected] wrote: >> >>> In my latest "brain-age" game (Coding Fun: My take on recipe ingredients >>> <https://groups.google.com/g/tiddlywiki/c/Ug8IsxJX0z8>), I've gone >>> all-in with structured data. >>> >>> *(Aside: I tend to prefer using data tiddlers over fields, but that's >>> the kind of conversation that deserves its own thread.)* >>> >>> Although structured data is very cool, I usually much prefer the >>> loosey-goosey unstructured data. >>> >>> Like just about all things, which is better (structured or unstructured) >>> >>> - it depends >>> >>> Structured data involves big effort up front, but with substantial >>> benefits later. >>> >>> - However, structure done wrong (big analysis up front did not >>> consider some things until elucidation happened while knee-deep in the >>> thick of it) can involve big effort re-jigging things if "quickly >>> adjustable re-design" wasn't built it. (Maintaining documentation, even >>> if >>> just bread-crumbs, makes a re-jigging effort so much easier, but even >>> maintaining bread-crumbs can be some effort.) >>> - Building structure for possible future needs that never happen, >>> that makes big effort up-front not so pretty re the cost-benefit ratio >>> >>> Unstructured data involves little effort up-front (immediate benefit), >>> but could require big effort later: i.e. having to move all of that >>> unstructured data into fields when structure is needed. >>> >>> Way too many thoughts about it all to write here. I'd need a dedicated >>> TiddlyWiki. >>> >>> All of that to say that my "brain-age" game of structured recipe >>> ingredients may turn into an expanded game that pits structured recipe >>> ingredients head-to-head with unstructured ingredients. >>> >>> Proof in the pudding, advantages and disadvantages to both, maybe some >>> trickery. >>> >>> Maybe via a shared TiddlyWiki running on nodejs, on a virtual machine, >>> if anybody is interested. I do have, I think, enough credit in my Google >>> Compute Engine to setup a virtual machine for some collaborative >>> "brain-age" structured vs unstructured recipe tomfoolery for a couple of >>> months... >>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/398fe33e-fde2-4218-9cbe-e7873f0fbc39n%40googlegroups.com.
