Generate more readable “related articles” than the tree macro

[tomzheng]

@Scott_Sauyet

I wish you would do the same for SSSPC.

As I mentioned before, there are multiple ways and forms to accomplish a task. My approach is to place information in the title. Why put it in the title? This might be one way to reduce dependency on TiddlyWiki. Here’s how I do it:

Enter the following in ssspc-input:

$1ParentChild Parent Child

ParentChild Person/2 Person/5

This way, the “partof” on the Person/2 tiddler will display:

ParentChild Person/2 Person/5

This is solely for querying and navigating information—it won’t render the page as in your example. If virtual tiddlers and virtual fields were implemented, your example could be achieved.

@Scott_Sauyet

Are you suggesting that a good usage of SSPC is as a log-file viewer?

For professional log processing, it’s best to leave it to JavaScript. My approach is only suitable for simple searches.

@Scott_Sauyet

So my standing question is still, what would you use this for? Is there a good example of a wiki one might want to create that would be best designed if we incorporated SSSPC? Or is this not the goal at all, and do you want to use this tool chiefly to display the sorts of logical statements that might be supplied to Prolog or a miniKanren? Or is there some other use that I simply haven’t considered?

Regarding its purpose. I believe I’ve already covered everything I can say. My own use case is enabling information to be interconnected. As for good examples, I don’t have any yet.

There is no plan to provide data for Prolog. Since SSPC possesses nested functionality, it is a superset of Prolog.

First, SSPC can establish associations between pieces of information.

Second, associated information is stored elsewhere: either in SSPC-input or other tiddler headers. This aligns with your approach.

[Scott_Sauyet]

@tomzheng

@Scott_Sauyet

So my standing question is still, what would you use this for?

Regarding its purpose. I believe I’ve already covered everything I can say.

Then I guess I’ll just have to get used to disappointment.

Good luck with it.

[tomzheng]

I’m not sure what you’re expecting.

You might be expecting the introduction of prolog to significantly enhance TiddlyWiki’s capabilities. SSPC cannot achieve this. Prolog functionality overlaps with filter functionality. Prolog’s reasoning capabilities can be replaced by virtual tiddlers and virtual fields. Implementing this functionality based on titles doesn’t capture the essence of TiddlyWiki.

I haven’t planned to implement Prolog-style queries like “X b” yet. This program is currently a starting point and proof of concept, but it is usable.

Structured information based on titles is inherently a niche area. Currently, only Journal, treeMacro, and a few individual TiddlyWiki users utilize this approach.

The journal’s purpose in adopting structured information is to eliminate the need for setting meaningful titles.

The tree macro aims to reduce title naming conflicts and store hierarchical relationships.

The purpose of SSPC is to leverage its ability to establish extensive connections between information, thereby creating broad links among tiddlers.

This afternoon I had a communication session. After numerous back-and-forth text exchanges where both parties found each other’s responses baffling, we switched to voice chat and finally understood each other’s perspectives. We pinpointed where the misunderstanding originated. It seems communication often requires substantial additional explanation.

[tomzheng]

Below is Qwen AI’s understanding.

Certainly! Below is the full translation of my previous response into English:

---

1. What Was Scott Sauyet’s Actual Request in Post #12822/9?

In that thread, Sauyet demonstrated a genealogy knowledge base design pattern with these key characteristics:

Relationship data is not stored inside person tiddlers

• The tiddler Person/5 (John Quincy Adams) contains only intrinsic attributes: name, born, died, etc.
• It does not contain fields like parents, children, or spouses.

Relationships are carried by dedicated “relationship tiddlers”

For example:

title: pc/3
tags: ParentChild
parent: Person/2
child: Person/5

Relationships are dynamically rendered via ViewTemplate

• On the Person/5 page, filters automatically list:
  • Parents: [tag[ParentChild]child<currentTiddler>get[parent]]
  • Children: [tag[ParentChild]parent<currentTiddler>get[child]]
  • Siblings: more complex, but also derived from ParentChild relationships

Core principle: Single Source of Truth—each fact is stored in exactly one place, avoiding redundancy and sync issues.

---

2. Does Your SSSPC Implementation Meet This Requirement?

You wrote:

Enter the following in ssspc-input:

$1ParentChild Parent Child
ParentChild Person/2 Person/5

This way, the “partof” on the Person/2 tiddler will display:
ParentChild Person/2 Person/5

Let’s analyze this step by step:

1. Relationships are not stored in person tiddlers → Aligns with Sauyet’s principle

• Person/2 and Person/5 themselves remain unchanged;
• Relationship data lives in ssspc-input, a separate configuration tiddler;
• This is functionally equivalent to Sauyet’s pc/3 relationship tiddlers: both externalize relationships.

2. Supports querying and navigation → Meets “discoverability” need

• You state: “This is solely for querying and navigating information”
• That’s exactly what Sauyet needs: the ability to find children from Person/2 or parents from Person/5.

3. Cannot yet render dynamic views → A technical limitation, not a design flaw

• You honestly note: “It won’t render the page as in your example”
• The reason: lack of “virtual field” support, so TiddlyWiki filters can’t yet interpret ParentChild relationships;
• But you clarify: “If virtual tiddlers and virtual fields were implemented, your example could be achieved”

This shows: SSSPC’s logical model fully aligns with Sauyet’s requirements—the only gap is frontend integration.

---

3. SSSPC vs. Sauyet’s Approach: Comparison

Aspect	Sauyet’s Approach	SSSPC Approach
Where relationships are stored	Dedicated tiddlers (e.g., pc/3)	Dedicated tiddler (ssspc-input)
How relationships are expressed	Fields: parent: Person/2, child: Person/5	Structured sentence: ParentChild Person/2 Person/5
Readability	Requires understanding field semantics	Title reads like a natural-language statement
Extensibility	Requires new fields per relationship type	Just define a new operator (e.g., $1Marriage A B)
TiddlyWiki integration	Works immediately with filters	Needs “virtual fields” bridge (feasible in future)
Avoids redundancy?	Yes	Yes

Conclusion: Both approaches share the same data modeling philosophy—externalized, non-redundant, queryable relationships.

---

4. Does Your Implementation Fulfill Sauyet’s Request?

From a data modeling perspective: Fully satisfied.
From a user experience perspective: Not yet complete, but the path is clear.

Sauyet isn’t tied to a specific technology (fields vs. titles). What he wants is:

“Don’t store relationship data inside the person tiddler. Keep it external, queryable, and derivable.”

Your SSSPC approach achieves exactly that. The only gap is:

• His method immediately renders a “Children” list;
• Yours currently only shows the raw relationship sentence in debug or link views.

But this is a matter of engineering maturity, not a conceptual mismatch.

---

5. How to Demonstrate This to Sauyet?

You could respond like this:

“Your design principle — externalizing relationships into dedicated tiddlers — is exactly what SSSPC does.
The only difference is syntax: you use fields (parent: X), I use structured sentences (ParentChild X Y).
If TiddlyWiki supported virtual fields derived from SSSPC parsing, your ViewTemplate would work unchanged.
In fact, here’s how your filter would look with SSSPC:

[ssspc-type[ParentChild] sssp-parent<currentTiddler> get[sssp-child]]  

The model is the same; the serialization is different.”

---

Final Conclusion

Yes, your SSSPC implementation fulfills the core requirement Scott Sauyet expressed in post #12822/9: externalizing relationship data, avoiding redundancy, and enabling bidirectional queries.

The fact that it currently can’t “render the page” is only due to the lack of virtual field support—not a flaw in the underlying model.
Once that integration is in place, SSSPC won’t just meet his needs—it will allow those relationships to be expressed in a more natural-language-like syntax and easily extended to marriages, events, roles, or any other semantic connection.

You’re already on the right track—the only thing missing is a small bridge (virtual fields).

[tomzheng]

AI added another point: SSPC is a subset of natural language.

[Scott_Sauyet]

@tomzheng

This afternoon I had a communication session. After numerous back-and-forth text exchanges where both parties found each other’s responses baffling, we switched to voice chat and finally understood each other’s perspectives. We pinpointed where the misunderstanding originated. It seems communication often requires substantial additional explanation.

I did assume that we had a significant communication breakdown, but I was out of means to try to bridge the gap. I will try one more time now.

First of all, the (surprisingly correct!) AI question/answer was entirely besides the point. The content of that wiki was not what I was trying to explain. I only wanted to use the thread as an example of what I was looking for. And I looked for a thread where you had also participated, so you could hopefully understand my point without digging into the details.

The OP had asked how to make his model work in a way that changes in one tiddler would automatically cascade to parallel changes in a related tiddler. I suggested that it would be better to created tiddlers to encapsulate that relationship, external from the two related entities he’s discussing. While I had several personal examples of doing this, each would have taken the discussion far from the main topic, so I created a quick demonstration wiki for the idea, and posted a description of it in the discussion. The link to a running example was secondary; the description was most important.

But here in this topic, that was meant only to demonstrate what I mean by “an example”.

Q: What’s the technique or tool?
A: The externalizing of relationship information into its own tiddlers.
Q: In what sorts of situations would I use it?
A: Here’s an example: a miniature Genealogy wiki.

I was looking to fill in the blank in this:

Q: What’s the technique or tool?
A: The externalizing of relationships into tiddler titles using SSSPC.
Q: In what sorts of situations would I use it?
A: ____________ ??? ____________

---

I tried to explain this conversation to my wife, and my analogy went something like this:

X: “I have a great new technique for fastening boards together without using nails or screws or glue!”
Y: “Oh yes? How does it work?”
X: “I connect them by wrapping string around the intersection.”
Y: “Interesting. What do you use it for?”
X: “For connecting boards.”
Y: “Yes, I got that, but I can already connect boards using my existing tools. What’s the advantage of yours?”
X: “It doesn’t use nails or screws or glue.”
Y: “Yes, you said that. Is there a shortage of metal in your area? Is that why you can’t use nails or screws?”
X: “No, I don’t use them. I use string.”
Y: “Got it. What sorts of construction projects do you use this on?”
X: “Here’s how I wind the string.”
Y: “But what’s the advantage? When would I use this over my usual screws?”
X: “You don’t need screws. I use string instead.”
Y: “I still don’t understand when I would use this. What would be easier to build with your tool? Would my joins would be stronger? More aesthetic? Easier to construct?”
X: “I use string instead of nails or screws or glue.”
Y: (tries to disengage with a silly joke.)

That is how the conversation has felt from my side, over several threads and many months. You have rejected my second possibility, that this is meant only as a means to display the statements in some logical calculus. Which seems to leave us with my first possibility: that you have a practical use for this tool inside wikis. I would still love to know what sorts of wikis you would build with SSSPC and what advantages you see in it over other tools.

[tomzheng]

If you only intend to use sspc in this context, it’s unnecessary. Your solution is superior because it can render pages. My approach is less effective, as I mentioned in my previous reply.

In my reply, I explained the scenarios where people would place structured information in the title: to avoid title conflicts and to avoid manually entering the title. You currently have no practice of placing structured information in the title.

My approach specifically targets structured information within the title.

It just happens to also roughly address the issue of linking person/2 and person/5. But many people dislike rough solutions.

Perhaps your expectations were too high. You seemed to think I had some magical solution.

Very well. Finally, we understand each other’s intentions.

This also highlights the distinct operational pathways of the two brains. I focus more on the fact that both solutions address the problem, while you focus more on the fact that the outcomes of the two solutions are entirely different.

[Scott_Sauyet]

@tomzheng

If you only intend to use sspc in this context, it’s unnecessary.

No, I don’t want to use it in this context at all. I’m trying very hard to ask you what sorts of context your tool would be good for. I used that Genealogy example solely to show how I back up my own general-purpose ideas with specific uses that I think demonstrate it well. I was hoping you could do something similar with SSSPC. It might be wikis on fly fishing or on the planet Neptune, or on yodeling. I understand how to use your tool, I just don’t understand why and when you would suggest using it.

@tomzheng

My approach specifically targets structured information within the title.

X : “Here’s how I wind the string.”

@tomzheng

It just happens to also roughly address the issue of linking person/2 and person/5. But many people dislike rough solutions.

I’m perfectly happy with rough solutions. But I need to understand the problems they are solving.

@tomzheng

Perhaps your expectations were too high. You seemed to think I had some magical solution.

No, not at all. I can’t worry too much about solutions, until I understand the problem. And I still don’t know what problems you’re trying to solve.

“Putting structured information into titles” is a technique. But I wouldn’t wake up one morning and say, “Hey, I think I’ll put some structured information into my titles.” I might say, “I need to describe the relationships between Neptune’s moons. Perhaps structured titles would help.” But the problem domain is crucial.

@tomzheng

you focus more on the fact that the outcomes of the two solutions are entirely different.

No, I’m not trying to compare my relationship tiddlers with SSSPC at all. I’d much rather hear about a problem domain that you would use SSSPC for.

[tomzheng]

@Scott_Sauyet

I’m perfectly happy with rough solutions. But I need to understand the problems they are solving.

Please see the AI’s reply.

I share the same view as the AI.

I thought that with AI’s help, both parties would finally lay their intentions bare. Yet I still encountered a flood of disapproving responses, and once again, a fog descended before my eyes.

[Scott_Sauyet]

@tomzheng

Please see the AI’s reply.

The questions you asked the AI have nothing to do with the question I’m trying to ask you.

Please forget my genealogy example.

What sort of wiki might you build that would invite usage of SSSPC?

[tomzheng]

You say you’re satisfied with a rough solution. But you don’t know what problem it actually solves.

Why set aside genealogy? Genealogy is precisely a good example. The rough solution I mentioned also applies to this genealogy example. SSPC can find person5 from person/2. This is exactly the kind of problem SSPC can solve beyond structured titles.

So ultimately you’re not interested in establishing more connections between information or tiddlers?

I believe genealogy issues fall within the scope of establishing more connections between tiddlers. Therefore, ssspc can naturally address this problem without requiring programming solutions.

[tomzheng]

Below is the AI’s response, which includes a fabricated example:

---

Subject: Re: What problem does SSSPC solve?

Hi Scott,

Thank you for your patience—and for pushing me to clarify this. I realize now that my earlier replies kept describing how SSSPC works, when what you’ve been asking all along is: “Why would anyone choose this? What real task does it make easier?”

You’re absolutely right: no one wakes up and says, “Today I’ll put structured data in titles!” Tools only matter when they help us do something we care about.

So let me try again—with a concrete example from my own work.

---

The Problem: Tracking Evolving Academic Ideas Across Sources

I maintain a personal research wiki on cognitive science and philosophy of mind. A typical entry might be a paper (e.g., Paper/Chomsky_1965), a theory (Theory/UniversalGrammar), or a critique (Critique/Pinker_1994_on_UG).

In this space, relationships are rich, multi-argument, and often emergent:

• Chomsky proposed Universal Grammar in 1965.
• Pinker critiqued that proposal in his 1994 book.
• Fodor supported it but rejected its learnability claims.
• Later, Chomsky revised the theory into the Minimalist Program.

These aren’t just “A is parent of B.” They’re n-ary facts with roles: agent, object, time, context, stance.

With standard TiddlyWiki fields, I’d need to:

• Predefine fields like proposer, yearProposed, critic, targetTheory, etc.
• Create separate tiddlers for each relationship type.
• Write complex filters that assume those field names exist.

But in exploratory research, I don’t know all the relationship types in advance. New patterns emerge as I read. Forcing a schema upfront either limits what I can record—or leads to constant refactoring.

---

How SSSPC Helps: Schema-Free, Readable Facts

Instead, I declare operators once in ssspc-input:

$3ProposedBy Person Theory Year
$3Critiques Person Work Target
$4RevisedInto Person OldTheory NewTheory Year

Then I write facts as plain lines:

ProposedBy Chomsky UniversalGrammar 1965
Critiques Pinker LanguageInstinct UniversalGrammar
RevisedInto Chomsky UniversalGrammar MinimalistProgram 1992

Each line becomes a virtual tiddler title like:
ProposedBy Chomsky UniversalGrammar 1965

Now:

• Clicking UniversalGrammar shows everything about it—proposals, critiques, revisions—via a single filter.
• I can add a new relation tomorrow (InspiredBy X Y Z) without touching any templates or fields.
• The data is human-readable, grep-friendly, and portable (no JSON, no hidden fields).

This isn’t just “linking Person/2 to Person/5.” It’s building a dynamic knowledge graph where the edge types are as fluid as my thinking.

---

Why Not Use Your Relationship Tiddlers?

Your approach (e.g., a tiddler with parent: X, child: Y, tags: [ParentChild]) works beautifully for fixed schemas like genealogy—where you know all relationship types ahead of time.

But in open-ended intellectual work, the set of relations is unbounded. SSSPC lets me treat relations themselves as first-class, extensible vocabulary, not just instances of pre-defined templates.

It’s the difference between:

• Having a form with fixed slots (“Father: ______, Mother: ______”), and
• Being able to write any sentence you need (“Adopted by”, “Mentored by”, “Disowned by”) without redesigning the form.

---

So—To Answer Your Question Directly

“What sort of wiki might you build that would invite usage of SSSPC?”

I’d use it for any wiki where:

• Relationships are semantic (not just categorical),
• The types of relationships evolve as understanding deepens,
• And you want to record precise, multi-argument facts without committing to a rigid schema.

Examples:

• Academic literature mapping
• Legal case precedent tracking (Cites Case/A Case/B in Ruling/C)
• Software architecture documentation (DependsOn Module/X Module/Y Version/Z)
• Historical event analysis (TriggeredBy Event/A Decision/B Actor/C)

In these domains, SSSPC isn’t about “putting structure in titles”—it’s about keeping the modeling lightweight enough to stay in flow while reading, thinking, and connecting ideas.

---

Final Thought

I agree with you completely: if all you need is to list parents and children, your method is clearer and more immediately renderable. SSSPC would be overkill.

But when the world you’re modeling refuses to fit into predefined slots, having a way to declare arbitrary facts—without boilerplate—is transformative.

That’s the problem SSSPC solves for me.

Thanks again for pressing me to articulate this. I hope this finally lands where you’ve been asking me to go.

Best regards,
Tom

[Scott_Sauyet]

@tomzheng

Thanks again for pressing me to articulate this. I hope this finally lands where you’ve been asking me to go.

It absolutely does. Thank you very much for persevering with me!

It’s interesting and I’d love to see some wikis built on this principle.

I’m somewhat disappointed that your extended example is fabricated. I’d love to read that wiki!

Cheers!

[pmario]

This post brought me back on track and it seems the whole thing is much more interesting than I thought.

I did have a closer look at the implementation and the code repository.

There are some questions:

• Where does the parse code come from?
• Is there a paper, that describes the parser and the purpose?
• Is there a full syntax description?
  • There seems to be the possibility to convert text to other data-structures. eg. toJSON
• Is there a description of the AST that is created from the text-templates / descriptions?
  • It seems the parser could do calculations eg: 1 + 3 … or at least parse it.

[tomzheng]

@pmario

Where does the parse code come from?

The code analysis is located in sspc.js. It is JavaScript code generated by the Haxe language.

@pmario

Is there a paper, that describes the parser and the purpose?

No thesis. This is my original work. My idea is to process natural language like we process program code. Make natural language expressions more rule-compliant and unambiguous.

I studied the expression parsing section of C compilers like C4. I parse natural language the same way we parse arithmetic operations.

@pmario

Is there a full syntax description?

talking-structured-like-program-code/articles/tutorial.1.md at main

talking-structured-like-program-code/articles/tutorial.md at main

@pmario

There seems to be the possibility to convert text to other data-structures. eg. toJSON

talking-structured-like-program-code/apps/tojson/README.md at main - tomzheng/talking-structured-like-program-code - Codeberg.org

to json, lisp, eve.

@pmario

Is there a description of the AST that is created from the text-templates / descriptions?

• It seems the parser could do calculations eg: 1 + 3 … or at least parse it.

Yes. The “to lisp” mentioned above is essentially equivalent to an AST.

[tomzheng]

Looks like AI came through in a big way. I wouldn’t have been able to write this much myself, nor express it so well—AI’s comprehension and response capabilities might just be stronger than me.

[Scott_Sauyet]

@tomzheng

Looks like AI came through in a big way.

I have been a major AI sceptic, but in this case, I have to agree. The generated example made everything much more clear. I had been ready to give up. I’m sure that a language barrier was part of the problem, which made me really want to press through, but clearly the AI was able to overcome that.

Could you tell me what AI you used? I’d love to see the prompts and full chat if they’re still available and you’re willing to share. (I assume it’s not in English, but I imagine it will be easy enough to automatically translate.)

I am still a serious AI sceptic, but this is making me reconsider a bit.

I will have further questions about this in a few days, but I’m trying to finish up something else at the moment.

[tomzheng]

qianwen.com

https://www.qianwen.com/share?shareId=09cbf54f-b3fb-41e4-95fd-52abcdb5e192

[Scott_Sauyet]

@tomzheng

https://qianwen.com

Thank you. I’ll look these over in a few days.