Generate more readable “related articles” than the tree macro

Plugins
,
#14

I’m curious as to how you would structure declarations for this, and how rigid they would be. For instance, in natural language, we might also write “George Washington was President between 1789 and 1797”. Or “Grover Cleveland was President from 1885 to 1889 and again from 1893 to 1897.” I wouldn’t be surprised if we needed to convert the latter to two separate facts; that just makes sense. But would we also need to settle on one of “served as U.S. President” and “was President”, and to settle on one of “from year1 to year2” and “between year1 and year2”, or are there mechanisms for such aliases?

In RDF that would be captured by a few separate facts, perhaps

| Tom   | has-sister | Becky   |
| Jerry | has-sister | Carolyn |
| Becky | teacher-of | Carolyn |

But, certainly, it’s not expressible in any reasonable way in just one triple.

I think this is a good part of what I was missing. I thought you were declaring these facts more explicitly (in that sidebar box, perhaps?) So a fact is a tiddler title? Interesting.

:100:

I didn’t either in the thread where I used it. I just created a very small wiki from an area that I thought would be widely understood (and which I wrongly thought was related to the OP’s goals) and used it to demonstrate a technique. To me that’s an important part of demonstrating ideas: show them in as realistic a a context as I can. I find that helps demonstrate their usefulness and their limitations.

In any case, this is very interesting to look at. I will try to dig into the implementation this weekend. I’m a sucker for a good parser!

#15

John-Quincy-Adams served-as U.S.-President from 1825 to 1829 One meaning is limited to one way of expression. Try not to have more than one way of expressing it.

What if you don’t know the name of Tom’s sister as well as Jerry’s sister? Nested structures can also be called anonymous records. Nested structures or called anonymous records save a lot of de-naming.

The person1 friend-of-person2

in (history of (person1 friend-of-person2)) is not only a relationship but also a title, and is also part of a title.

Of course, some relationships are not titles. It’s just recorded inside a tiddler.

#16

I just realized this project lacks complete documentation. I’ve now roughly filled in the gaps.

#17

That helps a little with the how. It would definitely have sped up my learning.

But I for one would love to see more of the why. Do you see this as a way to enhance certain data-heavy wikis? If so, what sorts, and how would you do do? Or do you see this as a way to use Tiddlywiki to display the results of your logic language? Are you using SSSPC as an extension to improve TW, or the reverse? Or something else entirely?

#18

Take a look at this topic. Using this method, any structured title can be parsed.

Like journals and trees, information resides within the title. Some clients also prefer placing details such as people, places, and times within the title. These are structured titles. If such structured titles can be separated by spaces, they can be linked together using sspc.

#19

I do understand that. And I saw that article as well.

But we seem to be talking past one another here. You were involved in another thread where someone asked how to keep changes in sync. I responded with an example of the sort of design I was promoting. But I could just as easily have given a description of it. In fact, I did give a reasonably thorough description as well as a link to a small running sample.

I wish you would do the same for SSSPC. That it can parse log files is… fine. Are you suggesting that a good usage of SSPC is as a log-file viewer? Because I would be surprised if TiddlyWiki would scale to handle the sorts of log files I tend to deal with in my day job, where hundreds of thousands, million, or tens of millions of records are common, not to mention the conversion efforts required from a plain text log file to a wiki.

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?

#20

If “virtual fields” are implemented, they can integrate with the TiddlyWiki ecosystem, such as filters.

For example:

log 2025 11 25

has virtual fields:

log-year:2025
log-month:11
log-day:25
#21

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.

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

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.

#22

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

Good luck with it.

#23

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.

#24

Below is Qwen AI’s understanding.

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

:mag: 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:

:white_check_mark: 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.

:white_check_mark: Relationships are carried by dedicated “relationship tiddlers”

For example:

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

:white_check_mark: 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

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

:jigsaw: 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:

:white_check_mark: 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.

:white_check_mark: 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.

:warning: 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”

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

:vs: 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? :white_check_mark: Yes :white_check_mark: Yes

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

:white_check_mark: 4. Does Your Implementation Fulfill Sauyet’s Request?

From a data modeling perspective: :white_check_mark: Fully satisfied.
From a user experience perspective: :warning: 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.

:bulb: 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.”

:pushpin: 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).

#25

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

#26

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.

#27

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.

#28

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.

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

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

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.

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.

#29

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.

#30

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?

#31

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.

#32

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

2 Likes
#33

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!