This looks really nice, Charlie. Let me know when you are ready for some beta testing. I have a couple of nice book projects where I could use Tifoist. Stan
On Tuesday, February 23, 2021 at 10:05:14 PM UTC-5 [email protected] wrote: > "ORM-ish à la TiddlyWiki" is now "*The Tifoist Project*" > > - *T*ifoist *I*s a *F*act-*O*riented *I*nformation-*S*emanticization > *T*ool > > > The previous work I now call "prototype 1." > > I am now labouring on "prototype 2", involving some GUI design and > overhauling/refactoring what I did in prototype 1. Much of what I did in > prototype 1 is now broken in prototype 2. > > Much work to do before prototype 2 can be released into the wild for some > scrutiny. For now, I share a few screenshots (attached). > > Cheers ! > > On Tuesday, December 1, 2020 at 4:49:31 PM UTC-4 Charlie Veniot wrote: > >> Project TiddlyWiki: ORM-ish à la TiddlyWiki >> <https://intertwingularityslicendice.neocities.org/CJ_ORM.html> >> >> *BTW: My announcement for this project has turned into an awesome thread >> of discussion. Please check out Using TiddlyWiki for fact-based >> information modelling and database engineering ??? >> <https://groups.google.com/g/tiddlywiki/c/57_eiPadjCo> for some >> ridiculously excellent buffet of food for thought about, um, thought >> (cognitive processing). Things like (I can't do it all justice):* >> >> - *managing complexity* >> - *information/knowledge design/navigation* >> - *PhD-related stuff about context and keeping stuff understandable* >> - *in short: A LOT OF WOW GOODNESS !!!* >> >> *Latest Updates* >> *(The following pretty much sums up changes/additions since November >> 23rd.)* >> >> *Text Rotation Testing* >> >> - I took a little side trip trying to figure out a generic mechanism >> from creating tables like in the "Entity Relationship Matrix" tiddler. >> Although I gave up after a few hours (much too big and messy of a job), I >> left the following two tiddlers in the TiddlyWiki in case I ever want to >> try again: "Research Macros" and "Text Rotation Tester" >> >> *Coded Form of Facts* >> >> - I last had coded form of facts setup as one field for each fact, >> containing the entire coding line (for example: coded field = "BUILDING >> 1:1 BLDG_NAME"). >> - That was making all of my scripting more complicated (having to >> split that coded field into the three parts: BUILDING, 1:1, and BLDG_NAME >> for whatever kind of processing.) MORE IMPORTANTLY: that was making it >> much more difficult for me to setup "data entry" of a fact's coded form >> via >> select widgets. >> - Now, a fact's coded form is split into three fields: c1, c2, and >> c3. (for example: c1 field = "BUILDING", c2 field = "1:1", and c3 field >> = >> "BLDG_NAME".) >> - This change from one field to three required some rejigging of >> various tiddlers, including (among others): "Entity Relationship >> Matrix", >> "oEs" (a transclusion template to generate conceptual representations of >> entities; see "BLDG_SPACE_UNIT" tiddler for an example) >> >> *Early start (experimentation) of widgets for data entry* >> >> - Using "select widgets" to help with creating coded form of facts. >> I'm very new to the use of widgets for this purpose, so this will take me >> a >> while to get right. For a starting example, see the "A Building has >> exactly one Name / A Name is unique to a Building" fact >> >> *Entity Relationship Matrix tiddler* >> >> - For the slanted column titles, I removed the little links for the >> related tiddlers, because the slanting of titles often causes the tiddler >> links to not be clickable (they wind up at the bottom of "z-order", and >> it >> just isn't a fun thing to try and fix at the moment.) >> - Pure CSS for tooltips on the check marks is wonky sometimes because >> of tooltip positioning (which can only be auto-adjusted nicely to show >> the >> tooltip, in a guaranteed viewable spot, with javascript.) That is not a >> fun thing to try and fix at the moment. >> - Scrolling the table columns towards the left: modified so that when >> columns get slid over to the left, the cells don't show on top of the row >> headers on the far left (that remain in fixed position.) >> - I haven't figured out how to do the same for column headers, but >> I'm on the fence: not sure I want to hide column headers when columns >> are >> scrolled to the left. >> >> *Primary Keys for entities* >> >> - I was setting up all primary keys as "value_type" tiddlers, but >> I've modified so that primary keys are now specified as a simple field on >> each related entity tiddler. >> - Seeing as I'm a big believer in using Sequence Numbers (as per >> Oracle Database products; whatever is equivalent in other database >> products), it doesn't make much sense for each primary key having a >> dedicated tiddler. >> - Instead, every entity has a sequence number name specified in a >> field, and each sequence number follows the exact same standard (data >> type, >> max length .... all of which are currently hard-coded in scripts; I >> plan to >> move those "standard sequence number details" in a data tiddler). >> - BTW: Related oEs template tiddler (for conceptualisation of >> entities) modified accordingly. >> >> *Conceptualisation of Entities* >> >> - For each attribute, the table now shows the related fact in a new >> column on the far right side. (Just nice extra information about each >> attribute). >> - TODO: setup some mechanism to specify an order for the attributes >> (likely up/down buttons with saving position in related fact tiddlers; >> still thinking about it.) >> >> *Task Tracking* >> >> - Renamed "Facts - Coded Form Pending" to "Facts - Incomplete Coded >> Form". >> - Got rid of "Entities/Attributes Pending Creation" tracking because >> "Facts - Incomplete Coded Form" handles that. >> - Added "Entities - Incomplete Primary Key" tracking. >> >> *Entity "... to Many" relationships with value types or with other >> entities* >> *(getting into some heavy-ish relational database design stuff here ...)* >> >> - In simple "... to 1" relationships, this would translate into one >> table for the one entity (for an entity relationship to a value type), or >> a >> table each for the two entities (for an entity relationship to an >> entity). >> Easy peasy. >> - However, for a case of "... to many", that introduces an additional >> table for both scenarios (1. relationship to many value type instances 2. >> relationship to many entity instances.) >> - That's something I need to ponder on: i.e. how to handle writing >> facts, coding those facts, and conceptualisation entities (i.e. the >> related >> scripts) >> >> >> -- 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/f0b6ab91-ef34-49f0-af6c-fee2bd19bffbn%40googlegroups.com.
