Yes, I thought I’d said as much. But it’s not that I would expect users to use such crazy JSON files; they are just convenient examples to demonstrate that there are ambiguities in any way we try to write single-string paths in a JS object. Because any string can be a legal key, it just gets crazy.
My basic take is this: I’m happy enough with the jsonget multi-parameter approach. I see no reason to try to add a single-parameter one. Still, I have no major objection to one, if people really want it. But if we do it, we need to very carefully document the restrictions on the sorts of JSON structures it can support. Because they could never be universal. (Unless my escape-character solution actually does work.)
Is it possible to use the jsonset Operator in a button for example to change the value?
This then lead to the ongoing discussion about how the JSON filter operators are somewhat complicated and that perhaps we could implement a simpler syntax that would allow people to use $transclude and $action-setfield with nested JSON objects without needing to use filter syntax at all.
In particular, in this post: Alternative Ways to Read JSON Data - #11 by EricShulman I compared the current filter-based syntax with some possible alternatives. Sure, they are really just “syntactic sugar”… but that’s often what makes things MUCH easier for people to understand, especially if they are not experienced coders (which is, after all, one of the goals of TiddlyWiki… to make complex tech more accessible).
Yes. I’d been following along, and that is where I jumped in.
My conclusion was in
my most recent post
I don’t deny that this syntactic sugar is sweet. But I don’t want us to pretend that it’s a proper meal. I think that if we do choose to do it, we need to make the limitations clear.
In an unrelated research exercise, I am looking at building an easy way to manage relationships between tiddlers. In its simplest form, one tiddler can name another in a field. eg; “person tiddler”, sets spouse=“spouse tiddler”, and we can even get the “spouse tiddler” to discover its spouse using the no touch methods in my flags POC. In many cases this may be sufficient.
However what if “person tiddler” has more than one spouse over time? Where the spouce field is a list field, In that case we may want to store other details about that specific relationship such as mariage and divorce dates.
Relavance to here?
I was hoping to store these extra details about a relationship, in a JSON tiddler with a compond key eg spouse/person-tiddler/spousetiddler then store additional details like dates for start/end of the relationship.
If I am honest I belive the cognative load to achive this in JSON, would be immense, especialy with current JSON tools and the aformentioned key issues.
I stand to be corrected, but it also raises questions if attempting to retain referential integrity with changes to relationships. Such as if “person tiddler” changes their name as a result of the start/end of the relationship. Common in many cultures.
Realisation
I have explored a solution using tiddlers to represent such relationships such as $:/spouse/person tiddler/spouse tiddler and this is very powerful.
The key realisation here is, If I use tiddler titles, I have a large suite of filter operators that let me handle such relationships. So I can find any relationship details whatever information is available to me for example;
prefix[$:/spouse/person tiddler] all “person tiddlers” spouse relationships
[suffix[/spouse tiddler] all “spouse tiddler” relationships (also flag mechanisium)
Conclusion
Perhaps if we had filters that would allow us to interogate a JSON tiddlers with these partial keys, I could push this design into one JSON tiddler. Keeping relationships within a single tiddler.
Note: because “Relationship” could easily have two very distinct meanings in the discussion, I am going to use “Marriage” as the term for any committed long-term romantic/sexual pairing, regardless of whether there are wedding vows involved. This frees “Relationship” to represent the various structured interconnectivities between tiddlers or other entities.
My personal preference for this is to use additional tiddlers. A single JSON tiddler might possibly work, but I think such relationship tiddlers often are worthy of inspection on their own. Often I will have ViewTemplates for them.
So perhaps I might have some Hollywood listing that included marriages between celebrities, (including Elizabeth Taylor) with Person tiddlers such as these:
+------------------------+ +------------------------+ +------------------------+
| title: id/12345 | | title: id/45678 | | title: id/67890 |
| tags: Person | | tags: Person | | tags: Person |
| name: Richard Burton | | name: Conrad Hilton | | name: Mike Todd |
| ... | | ... | | ... |
+------------------------+ +------------------------+ +------------------------+
+------------------------+ +------------------------+ +------------------------+
| title: id/23456 | | title: id/56789 | | title: id/78901 |
| tags: Person | | tags: Person | | tags: Person |
| name: Eddie Fischer | | name: Elizabeth Taylor | | name: John Warner |
| ... | | ... | | ... |
+------------------------+ +------------------------+ +------------------------+
+------------------------+ +------------------------+ +------------------------+
| title: id/34567 | | title: id/67890 | | title: id/89012 |
| tags: Person | | tags: Person | | tags: Person |
| name: Larry Fortensky | | name: Mike Todd | | name: Michael Wilding |
| ... | | ... | | ... |
+------------------------+ +------------------------+ +------------------------+
It takes this on directly, since people’s names are not the titles for our tiddlers. Instead we use some sort of opaque id, perhaps a sequence number, and perhaps a GUID, and perhaps even the value of some external id . I often choose instead of a single namespace as shown here, to have a namespace for each identity, for instance, Person/1, Person/2, … and Marriage/1, Marriage/2, … Either way is fine; the single-namespace avoids some duplication, but is less clear at a glance.
It also addresses this point
Tiddlywiki has a rich querying language for tiddlers. It does not have one for objects stored as JSON strings. JavaScript does. If we were doing things in JS, then such a store might be useful. In wikiscript it just makes sense to use tiddlers.
My intention is to use relationship for any kind of tiddler relationship, “Marriage" was just one example.
This is mine given the current state of complex keys, the subject of this thread.
However I would like this to not be the case, illustrating what I think is incomplete with JSON handling at present. I should be able to do this and decide in the solution we are developing.
To me it is an identified gap. One reason may include moving tiddlers into a JSON structure to remove them from the tiddler store eg archive, version copy. But also other data driven solutions.
The truth is we may be able to leverage the current JSON Tiddlers (in a plugin Format) but can we sufficenly query it?
Recent research points to multi-tids and other current formats, that may even be useful rather than JSON, its just sad JSON is not in a position to help.
About your examples;
My approach differs to yours for general Tiddler Relationships, I have an approach that only needs one tiddler in a relationship pair to “anounce that relationship” the (parent of the relationship), the other simply inherits the relationship (the child of the relationship).
This could allow referential integrity even without relink installed.
The intention is, if additional information is needed to be recorded for that relationship, such as married and divorced dates, as in your example, I want to manage this, not with an arbitary relationship ID, but with the actual tiddlers titles, yes there still is a “relationship tiddler” such as $:/spouse/person tiddler/spouse tiddler.
I feel this is more intutive and easier to handle for less expierenced designers. It is also more readable from a title list.
I would think in your example it may be better to have a title of the form $:/id/0987 to keep it out of the “tiddlers” list?
I understand how in your example by using an ID it does not matter if either tiddler party to the relationship is renamed the relationship remains. Although relink can save my approach.
Again thanks for your responce. I am not trying to argue for a best approach, only explain the approach I am developing and how if JSON was more powerful (I stand to be corrected) I could push these relationship records into a JSON.
For example imagin your solution storing the relationships, by ID in a JSON
I would think the tiddlywiki would lend itself for passing parameters into JavaScript to leverage existing JS methods. I am neither a JavaScript or json user but we go see it’s presence throughout tiddlywiki.
The main problem with JSON is, that it is not really human readable. The examples for the json-operators is “over” simplified, because it does not contain any linebreak or tab characters like \n\t in the value part. It also is “pretty printed” for human readability, where indentation levels indicate structure.
In reality JSON looks like this: {"a":"one","b":"","c":"three","d":{"e":"four","f":["five","six",true,false,null],"g":{"x":"max","y":"may","z":"maize"}}} which is completely unreadable and uneditable for humans.
Whereas compound tiddlers are human readable by design and can use the full range of filter operators, which are designed to deal with tiddlers.
It might be useful to have a format:json[] operator that takes JSON string input, and produces “pretty printed” JSON string output. It looks like it can be easily done using built-in javascript json handling:
JSON.stringify(JSON.parse(title),null,4))
This output would still be readable by jsonget[] and jsonextract[] operators.
I was using that to set the stage for the discussion in what I thought would be a much longer post. But it was late at night, and I dozed off several times trying to write it. I gave up and dropped much of what I was going to discuss. I just wanted to be clear that when I used “relationship”, I didn’t mean specifically romantic or sexual ones. If I’d been less drowsy, I would have removed that intro before posting it.
That said, it would certainly be possible to write such handling code for an underlying object model.
Pros
The current structure very much favors flat data structures. It can become awkward to model situations that would be best handled by nesting. JSON shines there.
It could be really useful for more robust importing and exporting, making it easier for TiddlyWiki apps to interact with external systems, many of which operate using JSON.
Cons
Everything is a tiddler. This guiding principal of TiddlyWiki would need to be shelved. There would be plenty of data that would not be tiddlers. (There is now, too, but we could patch that up with “everything is a tiddler… or a field,”) For instance, now, we might have tiddlers for people and addresses, so that we can find the person’s city with [<person>get[address]get[city]], because the address is itself a tiddler. If deep JSON storage became common, we would be dealing with two parallel data stores, with, I contend, little additional value. I’m not going to dig up the reference right now, but I’m quite sure that @jeremyruston has publicly regretted the introduction of data tiddlers. I’m guessing it’s for similar reasons.
[tag[Filter Operators]] returns 174 operators. At a rough guess, we would have to handle half of them for JSON, either replicating or expanding them to handle plain objects as well as tiddler titles. This is a lot of work.
JSON is a string format, meant for storing or transferring in-memory objects. It is not itself a real data format, and any serious work with it will entail converting input JSON strings into actual objects, manipulating those objects, and converting them back to JSON strings for storage. This is a likely a performance drain.
We already have an in-memory Object store. In a very important sense, that’s what TiddlyWiki is. Adding additional ones just complicates things.
You might want to look again at @tomzheng’s SSSPC work. That is discussing a similar idea, in a more abstract manner. I found it difficult to understand, and I created a summary of if in another thread. While I don’t see any use for that approach in my work, it’s definitely interesting in its own right.
My concern with putting the data into the title is the combinatorial one: It’s fine with any parent-child relationship (literal or figural) but gets stickier when it’s spouses: who do you put first? Even if we were restricted to traditional wife-husband pairings, that choice seems difficult, and when you move beyond that, it feels impossible, so you will probably end up with something arbitrary, such as alphabetic or by numeric id. And then searching can become awkward. If you move to relationships among three entities, it gets worse, because there are six orders they could come in. And it gets progressively worse.
That’s exactly how TW works. However, the methods that get called are usually not the primitive methods, but things that have been built atop those primitives for use in TW. We would need a similar layer for working with JS Objects.
It’s already there. The format Operator has a json suffix, and if you pass it a number, the output will be indented that number of spaces. And if you pass another string, it will be used literally as the indentation:
i presumed the format being native in js might reduce the complexity of such a task
but last i looked (bigger-er) strings in js where often less performant
so that might be “counting my eggs…”
written similar things in JS often enough
/ot-ish
begging the question ?!..
to what end ?
in what context (browser/or native-bin)
with what data (size-ez)
Either. I tend to write plain JS code that can be used anywhere JS is available. I’ve used similar code in both browser and Node, although much more of the latter.
All sorts of data. I’ve never really checked for size, but I’m sure it could handle inputs up to a few dozen MB.
