I’m not good at writing documents, so people can’t understand what I write.
SSSPC looks more like natural language.
SSSPC can express nested structures, and natural language does have nested structures.
You input a sentence, which can be parsed into several parts. Then you click on one of the parts, and it can find all the sentences related to that part.
Can I suggest that you create a miniature real-world wiki that uses your tool to describe certain relationships? That would show us how it works. I mean something like I created and described in a recent thread. Can you demonstrate how such relationship information would appear in the wiki? Would you extract it from the text field of a given tiddler? Is it in another field on such tiddlers? Is it in a single configuration tiddler? Something else?
Or, am I missing the point? Is this a tool that you’re working on, and only demonstrating, using TW as a documentation engine, but which is not itself meant to enhance TW?
I can see those. But I think I would need more comprehensive examples to see how this might affect me when developing a wiki design. Again, an extended example would be helpful.
Ok, I can certainly see that this is true syntactically. Could you suggest some real-world examples involving more than three components?
To start don’t assume any knowledge such as in your first post you seem to be saying we all know what SSSPC is, at least expand the acronyms. Do it in your post, not only out there in things you link to, no one (or few) will research the details if they dont know what you are talking about in the first place.
Similarly simplifying what you say using jargon or symbolic representation only makes it easy for people “just like you” to read, maybe only you, so you need to expand what you say to have its meaning self contained, not dependant on arbitary knowledge.
My reading habit is to skim or guess if I don’t understand. It doesn’t take into account that there are people who don’t skim any words.
Except for the acronym. Any other suggestions for this document? I’ve had two people test this document. The terminology has been removed. But at the moment the AI still can’t get the exercises exactly right.
This demo is already a real world example. And it’s also an example of your reply. I’ve read your REPLY and replied to that topic. SSSPC currently has no reasoning capabilities.The way SSSPC enters a line of text would be faster than adding a field, but is even less TiddlyWiki. SSSPC is only concerned with retrieving information, not typesetting the output, or the text field, it’s a single tiddler configuration file.
SSSPC uses TW as a document engine. Where it enhances TW’s capabilities is in the acquisition of “related reading” capabilities.
SSSPC is only for those who want the “related reading” feature, not for others.
nested structure: (history of (person1 friend-of person2))
My impression so far is that you’re not interested in the form of natural language, nested structures, more structures than triples, related reading, text input, retrieving document libraries from every word in the title, and these features. Maybe what I’m developing is supposed to be a niche software.
I think we have very different ideas, then, about real-world demos. When I look at your example, I don’t know what the wiki is built for. The example I linked to above is a wiki showing a partial genealogy of a famous American family. It directly encodes only the Parent/Child relationship, but derives others like Sibling, and implicitly (and only for its time Marriage) relationships. The idea was to demonstrate that I don’t have to have children, parents, or similar fields in my main tiddlers, but can use external relationship ones.
Perhaps I simply don’t have the imagination necessary, but I haven’t found an example of where I would want to use your (very interesting!) tool. I was hoping you could supply such motivation. Feel free to adapt my wiki to your techniques. Perhaps it would involve such predicates as “John Quincy Adams served as U.S. President from 1825 to 1829”?
I created a plugin for a list of neighboring tiddlers. It’s still in an alpha stage, and I don’t know that I will ever get back to it. But it’s almost the polar opposite of your approach; the goal was to entirely derive the idea of nearness from the wiki structure (links, tags, fields, transclusions, etc.) Yours seems to be to explicitly declare the relationships – with an interesting natural language-like mechanism.
If I want that, I would probably want it in the footer of a tiddler, not in the sidebar. Will the mechanism allow me to do that?
I’m not sure. I’m fascinated by the concept, but don’t really understand well enough to know if it’s something I would want. That’s why I’m trying to tease things out here. Perhaps it is something I would love to have. Perhaps not. I just can’t tell yet.
Your example is an example of nesting. Using ssspc you can answer who are the presidents of the United States.
An example of superiority over RDF. “Tom’s sister is Jerry’s sister’s teacher”.RDF can only express teacher relationships. And ssspc can also answer the question of who’s sister is involved inside the document library. Just click instead of re-searching.
The ssspc just discovers information from the title.
It doesn’t just declare relationships. Rather, it breaks down each word of the title with a nested structure.
You can. I added this section to the website.
You can say what part you’re interested in, then name your specific example, and then I’ll say how ssspc works.
The character relationship example, I think that’s what I demonstrated in my demo. As I also said, ssspc has no reasoning function, only the simple ability to retrieve interrelationships. I don’t have a genealogy requirement, so I don’t have relevant more examples here.
The table part of the previous reply is an example of what I use on a daily basis.
If you use ssspc to parse the title, there will be some limitations on the title, can not realize all natural language, but a subset of natural language. Just like tree macro, it doesn’t look like pure natural language. But it will be more natural than tree macro, for example, tree macro is like this a/b, ssspc is like this b of a.
Actually ssspc is very simple. @Ste_W understand the principle from a few instructions. The explanation part of the tutorial, including examples, is only a few dozen lines of text. Understand the principle, naturally know what effect ssspc has.
Or you can open the URL below and observe the results on the right. Then click on each link in PARTS and observe the results. You’ll see what sspc can do.
There is a concept here called full parsing. A mix of documentation and wiki links is called fragment parsing in the documentation.
The ssspc can be used in place of tags and backtags because it allows for link jumping.
ssspc can replace fields because it has RDF functionality. And the value of a field is a link, so that it has knowledge graph functionality.
ssspc can replace search. Provided the title is fully parsed. The advantage of this kind of search is that the search results don’t become unreadable because there are too many of them. Because it searches for fragments, not whole sentences.
For example, a search for person1
will give you person1 friend-of-person2,
not history of person1 friend-of-person2.
When you click whole
to switch to person1 friend-of-person2 ,
you get history of person1 friend-of-person2.
ssspc can be used instead of tree macro. you can browse to the higher level of directory or the lower level of directory. both tree macro and ssspc are composite IDs. composite ID means several IDs are combined to make a new ID.
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
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.
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!
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.
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?
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.
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?
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:
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.
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.
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:
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).
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.
1. What Was Scott Sauyet’s Actual Request in Post 
Relationship data is not stored inside person tiddlers
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?
3. Cannot yet render dynamic views → A technical limitation, not a design flaw
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
Final Conclusion