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 cj.v...@gmail.com 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a50e0374-c66f-402e-bddf-3ae54b10104an%40googlegroups.com.
