[tw5] Posts should be now cross-posted to the Talk TiddlyWiki Discourse again

[Boris Mann]

For those that are interested, it was related to an SSL / root certificate that 
caused havoc all over the Internet. The Discourse team made an update which 
appears to have fixed it.

Further details / comments / questions in the meta thread here: 
https://talk.tiddlywiki.org/t/seems-like-new-gg-posts-do-not-show-up-in-tiddlytalk/969/14

--
Boris Mann, Co-founder
Fission: Fast app publishing for front end devs to ship web native apps

-- 
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/5a77c6c9-5608-473f-90e4-365edf09eeac%40missiveapp.com.

[tw5] Re: To structure or not to structure? Depends, eh?

[Charlie Veniot]

Pff, it is stuff that has been swirling and expanding in my head since the 
early 90's and I still can't coherently spell it out.

You've got it down to an art-form from my perspective.  I am frigging 
envious.

On Tuesday, October 5, 2021 at 12:17:08 AM UTC-3 TW Tones wrote:

> 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 cj.v...@gmail.com 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 cj.v...@gmail.com wrote:
>>>
 In my latest "brain-age" game (Coding Fun: My take on recipe 
 ingredients ), 
 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 

[tw5] Re: To structure or not to structure? Depends, eh?

[TW Tones]

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 cj.v...@gmail.com 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 cj.v...@gmail.com wrote:
>>
>>> In my latest "brain-age" game (Coding Fun: My take on recipe ingredients 
>>> ), 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 

[tw5] Re: To structure or not to structure? Depends, eh?

[Charlie Veniot]

Anybody interested in this kind of stuff, I am influenced by (re software 
development, database development, and "intertwingularity mapping"):


   - *Scott Ambler*. 
   

  - Scott Ambler's Home Page 
  - Agile Modeling 
  - Agile/Lean Documentation 
  

   

   - *Ted Nelson*. 
   

  - Ted Nelson's YouTube Channel 
  
  - Wikipedia's Ted Nelson Article 
  
  - Intertwingled: The Work and Influence of Ted Nelson 
   
*(Internet 
  Archive)*
   

   - *Open Knowledge Foundation*
  - Home Page 
  - The Four Principles of (Open) Knowledge Development 
  

  - What Do We Mean by Componentization (for Knowledge)? 
  

   

   - *Software Development*. 
   

  - Agile Software Development 
  
  - Lean Software Development 
  
  - Object-oriented programming 
  
  - Rapid Application Development 
  
   
*(I won't get into the various Zen Buddhism and Tribal Wisdom 
stories/sayings/etc. I rather like and funny jokes/stories/analogies I've 
read over the years.)*

Aside:  Intertwingularity Mapping 

 
(a work in progress that has been gathering dust.)
On Monday, October 4, 2021 at 11:50:57 PM UTC-3 Charlie Veniot 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 

[tw5] Re: To structure or not to structure? Depends, eh?

[Charlie Veniot]

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 
>> ), 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" 

[tw5] Re: To structure or not to structure? Depends, eh?

[Charlie Veniot]

Well, yeah.  I live in the gray.

Everything you're talking about, that was the whole point of this little 
project I had in mind:   pit the two extremes against each other, and then 
drop in everything in between.

It is what I hope my (subsequently posted) "Collaborative Recipes 
TiddlyWiki (Case Study) " winds up showing for 
reals.  A large variety of ways to enter/manage recipes (ingredients etc.) 
with various degrees (a whole spectrum?) of structured data and 
organization, with the added fun of finding ways of intertwingling 
information structured very differently together.

And then see whether or not various ways start converging.

Even if they don't an exercise of combining the structured and the 
unstructured might involve some interesting filtering, and I do love 
filtering.

Along with a practical showcase of tiddlywiki ways of thinking.


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 
>> ), 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 

[tw5] Re: To structure or not to structure? Depends, eh?

[TW Tones]

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 
> ), 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 

Re: [tw5] Announcing the release of TiddlyWiki v5.2.0

[Hans Wobbe]

Thank you very much!

This looks like it will be a significant watershed for me and my 
Associates.  We will be a while upgrading our existing capabilities and 
learning how to use the new release in the relatively complicated 
environment that has grown up around us.  Once that is over, however 
(perhaps before the end of this calendar year), I am hopeful that we will 
be able to contribute more back to the community.

Cheers!
Hans


On Sunday, October 3, 2021 at 12:38:40 PM UTC-4 jason...@gmail.com wrote:

> Thank you !!
>
> On Sun, Oct 3, 2021, 16:41 Jeremy Ruston  wrote:
>
>> I'm delighted to announce the release of TiddlyWiki v5.2.0 at:
>>
>> https://tiddlywiki.com/
>>
>> This release is a huge release. It has been under development for 286 
>> days, and includes improvements from 33 individual contributors on GitHub. 
>> There's a graph on GitHub that shows clearly how many people now regularly 
>> contribute to TiddlyWiki's development:
>>
>>
>> https://github.com/Jermolene/TiddlyWiki5/graphs/contributors?from=2020-12-24=2021-10-03=c
>>
>> My sincere thanks to everyone who has contributed or helped in any way.
>>
>> With v5.2.0 we've been able to address some long-standing frustrations:
>>
>> • It is now possible to use the edit widgets with a different field of 
>> the current tiddler
>> • The characters used in fieldnames are no longer restricted to lowercase 
>> letters, digits, and simple punctuation
>> • Images can now be dragged directly into the tiddler editor to import 
>> them and insert [img[foo]] at the cursor position. The title of the image 
>> tiddler can be edited too
>> • Macro calls can now be nested. For example <> <>">>
>>
>> See the release note for the full list of changes:
>>
>> • Some significant performance improvements
>> • Usability improvements
>> • New and improved widgets
>> • New and improved filters
>> • Improvements to the Markdown, XLSX, KaTeX, Freelinks, Menubar and 
>> BibTeX plugins
>> • Improved translations for Catalan, Chinese, French, German and Spanish
>> • A new Polish translation
>>
>> You can upgrade your existing single file wikis here:
>>
>> https://tiddlywiki.com/upgrade.html
>>
>> For Node.js users, the new version is available on npm:
>>
>> https://www.npmjs.com/package/tiddlywiki
>>
>> As ever, exercise caution when upgrading, and be careful to keep backup 
>> copies of everything important.
>>
>> Any questions or comments are welcome here, or via GitHub.
>>
>> Finally, I'd like to again express my thanks to everyone helping with 
>> this project. It's been a difficult time for all of us, but the steady 
>> progress we're making on TiddlyWiki inspires me for a future where diverse 
>> people can work together to achieve sustained, meaningful change.
>>
>> Best wishes
>>
>> Jeremy
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywiki/CA42E2B7-A3C1-4535-83FA-DBD37DD175B6%40gmail.com
>>  
>> 
>> .
>>
>

-- 
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/2c40bc4d-a645-46d0-bc15-c71eb42d246bn%40googlegroups.com.

[tw5] Re: Tiddlywiki - Database

['Bapak Ireng' via TiddlyWiki]

Hi, many thanks for your support and efforts  to get it to work.

Sorry, that I could not get earlier back to you, because i was off for a 
weekend trip!

Again, many many thanks !

Now, I will modify the Contact database to use ist as a small system to 
record my car expenses.

best regards, Ireng



strikke...@gmail.com schrieb am Samstag, 2. Oktober 2021 um 18:18:41 UTC+2:

> Okay, I tried to make it word with TW5 5.23.
> Download the attached file. Drag and drop it into you Tiddlywiki to import 
> the necessary tiddlers and see how it goes.
>
> On Saturday, October 2, 2021 at 7:53:17 AM UTC+2 strikke...@gmail.com 
> wrote:
>
>> The simple Contacts DB uses Newtiddler Widget from Stephan Hradek. That 
>> got incompatible with later versions of Tiddlywiki.
>>  It is more than 7 years old now. 
>>
>> On Saturday, October 2, 2021 at 6:48:50 AM UTC+2 bapak...@googlemail.com 
>> wrote:
>>
>>> The URL requested:
>>>
>>> http://tw5magick.tiddlyspot.com/
>>> Creating a simple Contacts DB
>>>
>>> regards, ireng
>>> strikke...@gmail.com schrieb am Freitag, 1. Oktober 2021 um 19:41:06 
>>> UTC+2:
>>>
 Do you have a link for the database you found?

 On Friday, October 1, 2021 at 6:19:27 PM UTC+2 bapak...@googlemail.com 
 wrote:

>
> Hi Folks,
>
> I am a new user to Twiddlywiki and i am still looking around to get 
> along with the system. During my small research I found a sample contacts 
> database. However I did not get it to run successfully with the current 
> Version 5.1.22. I would like to adopt it run it as a small and easy 
> record 
> keeper for my car expenses.
>
> Could anybody point me to a working solutiuon to start with ?
>
> I appreciate very much any valuable input.
>
> best regards, ireng
>


-- 
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/8fbf8201-45b0-4e75-9e3d-1a679c1419e9n%40googlegroups.com.

Re: [tw5] Announcing the release of TiddlyWiki v5.2.0

[Jeremy Ruston]

> Congrats!  This is very exciting.  Does this affect node.js' storage of 
> tiddlers at all at this time?  i.e. Are they stored as json, or in the .tid 
> file format still?

No, the JSON store area is only used with the single file edition. There are no 
major changes to the way that tiddler files are stored under Node.js

Best wishes

Jeremy

> 
> Matt Lauber
> 
>> On Sunday, October 3, 2021 at 12:38:40 PM UTC-4 jason...@gmail.com wrote:
>> Thank you !!
>> 
>>> On Sun, Oct 3, 2021, 16:41 Jeremy Ruston  wrote:
>>> I'm delighted to announce the release of TiddlyWiki v5.2.0 at:
>>> 
>>> https://tiddlywiki.com/
>>> 
>>> This release is a huge release. It has been under development for 286 days, 
>>> and includes improvements from 33 individual contributors on GitHub. 
>>> There's a graph on GitHub that shows clearly how many people now regularly 
>>> contribute to TiddlyWiki's development:
>>> 
>>> https://github.com/Jermolene/TiddlyWiki5/graphs/contributors?from=2020-12-24=2021-10-03=c
>>> 
>>> My sincere thanks to everyone who has contributed or helped in any way.
>>> 
>>> With v5.2.0 we've been able to address some long-standing frustrations:
>>> 
>>> • It is now possible to use the edit widgets with a different field of 
>>> the current tiddler
>>> • The characters used in fieldnames are no longer restricted to 
>>> lowercase letters, digits, and simple punctuation
>>> • Images can now be dragged directly into the tiddler editor to import 
>>> them and insert [img[foo]] at the cursor position. The title of the image 
>>> tiddler can be edited too
>>> • Macro calls can now be nested. For example <>> <>">>
>>> 
>>> See the release note for the full list of changes:
>>> 
>>> • Some significant performance improvements
>>> • Usability improvements
>>> • New and improved widgets
>>> • New and improved filters
>>> • Improvements to the Markdown, XLSX, KaTeX, Freelinks, Menubar and 
>>> BibTeX plugins
>>> • Improved translations for Catalan, Chinese, French, German and Spanish
>>> • A new Polish translation
>>> 
>>> You can upgrade your existing single file wikis here:
>>> 
>>> https://tiddlywiki.com/upgrade.html
>>> 
>>> For Node.js users, the new version is available on npm:
>>> 
>>> https://www.npmjs.com/package/tiddlywiki
>>> 
>>> As ever, exercise caution when upgrading, and be careful to keep backup 
>>> copies of everything important.
>>> 
>>> Any questions or comments are welcome here, or via GitHub.
>>> 
>>> Finally, I'd like to again express my thanks to everyone helping with this 
>>> project. It's been a difficult time for all of us, but the steady progress 
>>> we're making on TiddlyWiki inspires me for a future where diverse people 
>>> can work together to achieve sustained, meaningful change.
>>> 
>>> Best wishes
>>> 
>>> Jeremy
>> 
>>> -- 
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/tiddlywiki/CA42E2B7-A3C1-4535-83FA-DBD37DD175B6%40gmail.com.
> 
> -- 
> 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/db556eaf-1df6-466e-b658-8936f7af2b44n%40googlegroups.com.

-- 
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/8422FE14-5FAD-47A9-B5D5-9B5B4872EDF7%40gmail.com.