How to create field relationships, where modifying a field in one tiddler modifies a field in another

#5

I agree with everyone here that doing one or the other will make your life much easier down the road. I’ll offer a reason to store things at the parent level though instead of the child level. Essentially, SORTING.

If you just store the name of the parent for each child, there’s not a real way to maintain any manual sorting (if that may be desired). If you however on the parent tiddler use the list field (or any other but list offers some conveniences) then you have a sort order that can be maintained. Listing the children from the parent is just [list<currentTiddler>] and finding the parent from a child is just [<currentTiddler>listed[]].

In fact you’ll notice that core tag behavior is that when you do drag-and-drop sorting within a tag pill, that’s stored in the list field of the tag tiddler, just as I’m describing, so it’s a well supported method.

3 Likes
#6

It’s rare for me to desire a genuinely manual (arbitrary) sort; bibliographic subentries —and children — both tend to have a natural order that tracks something (page, birthyear) that’s already easy to reference…

But certainly if you do want such a thing (to order children by current-preference-ranking-according-to-this-parent :stuck_out_tongue: or some such), then the list field for the parent tiddler is the best place to do it (and once you have that list field, it ought to be the “home” for such data).

#7

Alright, I think I understand the benefit of using only a “parent” field and then generating the “children” within the tiddler for the parent. But what if a relationship is mutual, like (in keeping with the example of a person) a “spouse” field or a “friend” field? What would be best practices there?

#8

And thank you for providing a solution that solves the problem exactly as I wrote it, even if storing the data that way is not best practice.

#9

You can create a list field that contains multiple titles to link to other relationships or just link to them in the body. Try ctrl-L in the text editor to see how easy this is.

  • Of course installing RELINK plugin is all but essential, if not essential to maintain referential integrity if a rename happens.
#10

Welcome, @Ryan_Quinn to the talk forums!

I have a substantially different approach.

This is a demonstration of using small external tiddlers to maintain relationships between content tiddlers. You can see all the People in this wiki, who are extracted from the Adams family tree on Wikipedia: John Adams (the second president of the U.S.A), his wife Abigail Adams, and a few generations of their descendants.

If you view a person, say John Quincy Adams, you will see a reasonably robust template describing his vital stats and relationships:

Screenshot_JPA
Screenshot_JPA1094×933 57.4 KB

But if you edit this tiddler, you will see that none of the relationship information—parents, children, siblings—is actually included in this tiddler. The only custom fields are name, born, died, caption, and where needed, maiden-name.

Screenshot_JPA_edit
Screenshot_JPA_edit1093×957 51.3 KB

Instead of putting the relationship information inline, we have a number of separate ParentChild tiddlers that have only a numbered title, the tag ParentChild, and parent and child fields, which each have the title of another Person:

<!-- John Quincey Adams is `Person/5` -->
<!-- These are his parents -->

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

title: pc/4
tags: ParentChild
parent: Person/1
child: Person/5

<!-- and these are his children -->

title: pc/10
tags: ParentChild
parent: Person/5
child: Person/9

title: pc/12
tags: ParentChild
parent: Person/5
child: Person/10

title: pc/14
tags: ParentChild
parent: Person/5
child: Person/11

These are used by the ViewTemplates named $:/_/my/viewtemplates/person, to display those parents, children and siblings. For example, we list the Children like this:

  <% if [tag[ParentChild]parent<currentTiddler>] %>

    !!! ''Children''
    <<list-links filter:"[tag[ParentChild]parent<currentTiddler>get[child]sort[born]]">>
  <% endif %>

Parents is similar. Siblings is significantly more complex.

We could extend this to First Cousins, or add a recursive version of Descendants. If we added gender fields, we could also do Aunt, Uncle, Niece and Nephew. We could track half-siblings and step-siblings, and many other relationships, all within our templates, without adding any data. We could add other relationship tiddlers, for instance, Spouse.

You can also look at the Families tiddler, for another view of this data.

There is work to do to set this up. You need to create all those relationship tiddlers. To do so, I often add helpful input screens. Here, I have Add Family, which lets me pick the parents and children, click a button and have the relationship tiddlers added for each parent-child combination from my inputs.

This is not a panacea. The filters for siblings are non-trivial, and cousins would just be harder. But it’s powerful and I find it very useful.

2 Likes
Generate more readable “related articles” than the tree macro
#11

Update:

In my previously posted solution, I suggested that you

While this works, it only handles saving the tiddler by clicking on the “done” (checkmark) button. However, you can also trigger the <<save-tiddler-actions>> without clicking the “done” button by using the ctrl-enter keyboard shortcut while the focus is in a tiddler input field. This trigger is defined by a $keyboard widget that is directly in the $:/core/ui/EditTemplate tiddler.

So, in order to cover BOTH use-cases (clicking the “done” button OR using ctrl-enter), the best place to make your change is in $:/core/ui/EditTemplate, by adding the call to <<save-tiddler-actions-custom>> at the beginning of the save-tiddler-actions() definition. This ensures that regardless of how <<save-tiddler-actions>> is invoked, your extra “side effect” handling is performed.

The rest of my instructions (i.e., defining the save-tiddler-actions-custom procedure) remain the same.

enjoy,
-e

2 Likes
#12

Yes! This is exactly what I would find most logical if I had a wiki really focused on people and their relationships. (I know I suggested, above, making a parent field within the child tiddler. Which way to go depends on your situation and the needs of the project.)

In particular, with marriage or other reciprocal relations, a robust solution would want to allow that a person can participate in more than one over the course of time. If your approach is field-based, and there’s just one “spouse” field, then you would need to figure out whether to replace contents of a spouse field (losing real relational info) or whether to make a “spouse #2” field (also a mess for various relations), etc. But If a marriage is itself a tiddler as suggested by @Scott_Sauyet, then the information lives in one place, and can have start and end dates, plus other fields that might be genuinely specific to that marriage.

One risk that comes with putting relationship info in distinct tiddlers is that you need to anticipate some future contingencies. In particular, name changes…

Especially if you have a large project of this kind, you’d want to be careful to set up tiddler titles in a way that preserves uniqueness and flexibility in connection with ordinary names. Indeed, human beings can change their names, and it’s important that changing a person’s name can happen without losing the continuity of an individual’s info (and relationships) over time.

If names are tiddler titles, which then function as a key field for relationship connections… some of the risks of this easy approach are addressed by relink-type solutions now built into TiddlyWiki — so that if you change the name of a tiddler, you’re prompted about whether to change apparently related instances of that name in links and fields. Still, such solutions might leave some unexpected gaps that require caution.

We do have some genealogy wiki experts in the house… @clsturgeon comes to mind…?

2 Likes
#13

I replied to the OP on a duplicate post on Reddit. My response was similar to those here. ie avoid duplicate linking. In the Memory Keeper I have dedicated father and mother title fields for biological relationships. That’s it. I use a spouse list field for spouses. One more… an adopted list field. From there users can create their own relationships. These are set up like the spouse list field.

I guess I avoided a relationship tiddler type. Relationships, those non-blood, are dynamic… they come, they go, they come back. Marriage, divorce, etc are events, so users use an event to capture these.

And, yes I use the name of the person for the tiddler title. Without Relink plugin this would be a non-starter. I recommend the user use the birth name of an individual/title. I use an Aka field for alternate names, different spellings, nicknames etc. Name changes, in my mind, are events.

With blood relationship only being defined via a father and mother field made it ideal for writing TW filter operators like:

ancestors[]
descendants[]
uncles[]
aunts[]
siblings[]
cousins[]

2 Likes
#14

That’s an interesting insight. My version sounds similar to yours, except that I externalize Mother/Father (without distinguishing them; for something more than a POC, I would.) Marriages I did assume to be events but perhaps almost everything should be fluid this way. Keep an id, dob, date of death (if known), and use event tiddlers tied to that id for everything else: marriage, divorce, birth of a child, name change, sex change, etc. To know someone’s marital status at a given point, just look through the related events preceding that time. And that makes me even reconsider dob/date of death fields.

As to the names, I think as wikis add functionality or data, it gets trickier and trickier to use tiddler titles. Of course we all can imagine things we’d change about TW if we could go back in time. The top of my list is using a field called title and often meant to be a title, for the tiddler’s unique id. I think life would be much easier with a unique generated id instead.

#15

I appreciate all of the responses here, and you’ve all certainly given me a lot to think about.

I think that Scott_Sauyet’s solution is probably going to solve the most problems for me while still allowing me to maintain the best practice of not duplicating data, and I can probably use this approach for multiple types of relationships within my project. That said, I’ve realized two potential problems with this approach that I wanted to run by all of you:

  1. Naming of relationship tiddlers – If I use separate tiddlers for every relationship, naming those relationships could start to pose an issue. For instance, if I take the approach of just naming them “rel” and then adding a number, would it not make figuring out what that relationship is or finding later very difficult should I need to edit it? What would be best practice here?

  2. Number of relationship tiddlers – I can see how this approach could become very cumbersome very quickly, with some tiddlers potentially having tens of relationships. When multiplied across hundreds of individual tiddlers, you’re looking at thousands of individual relationship tiddlers. Would that cause any problems down the line?

Thoughts?

#16

I’ve done a few data models and each time I have not implemented a dob or dod attributes for a person entity. I suspect most applications have these. To me birth and death events are events. Separating them from the event entity will make it tougher to draw a timeline. I took events to another level. Events can be part of a greater event. Eg. The death of Tecumseh is child event to the Battle of the Thames; which is a child event to the War of 1812. Tough to do with a dod field. Another dimension of an event are the other people that participated in the event, capturing the role they had in the event. I’m researching beyond names and dates. I’m researching battles in WW1, WW2, and War of 1812. I research Indigenous Treaties and various colonial and Indigenous battles. I research organizations: business, military and Indigenous Nations.

1 Like
#17

One way I have designed to handle this is leveraging relink but also providing the tools to rename or change relationships, if it is likely to result in a loss of information such as remove or change a spouse name/link to log this to a transaction tiddler. This can mean you do not loose information. But of couse it raises the issue of when someone was a spouse start and or end, do they stop being a spouse when the other dies etc…

  • An appropriatly maintained transaction history can then be walked back to see the data accross time.
#18

I think a relationship tiddler can work. Some data models have a family entity to fulfill that. I don’t. I see family as something that can be determined vs explicitly defining it.

Your concerns are valid. The volume may not be a direct issue except when you want to write a relationship calculator, where you provide two individuals to a method and it returns the relationship. The calculator has to recursively go through the person and relationship / family tiddlers. All doable. If done correctly, I suspect it would be no more taxable on the system than my model.

However, it will be another entity to maintain and that is the concern with your first point. Not sure I have good answer for this. In my solution I don’t expect the user to use the TW edit fields. I provide my own to fill those TW fields. This helps with data integrity. With that, one could auto generate relationship tiddlers without the user knowing they exist. Provide appropriate controls to add, edit, and delete relationships.

#19

Not tiddlywiki.

Please ignore this reply

This is an example of a friendship

query and click - Structured speech similar to writing programming code (ssspc)

#20

Not tiddlywiki.

Please ignore this reply

This is an example of a event

https://tomzheng.codeberg.page/talking-structured-like-program-code/example/event.html

#21

I do take the route of naming them just something like rel/NNN. In my case, I had a specific name for ParentChild relationships, so they were pc/1, pc/2, … As @clsturgeon suggests, these can also be in the system namespace, hidden from casual searches: $:/pc/1, $:/pc/2. Here I choose to have a different namespace for each type of relationship. If I were to include marriages, they might be mrg/1, marg/2, etc, with the tag Marriage.

If you do it this way, with a generic rel for all relationships, I would suggest adding a rel-type field or adding a tag that distinguishes them. Otherwise, you’re right, it would be challenging to understand them, and impossible to search.

This would also lead me to consider having at least two different types of relationship tiddlers: directed and undirected. Parent-child is directed; each person in the relationship has a distinct role. Marriage is undirected; these days for instance, you can’t assume “husband” and “wife”, example.

Personally, I use a single namespace for a single kind of relationship. For me, that’s cleaner. But your mileage might vary.

Anything can run into problems if you scale it large enough. But I have wikis of over 30K tiddlers with no problems. I’m pretty sure I’ve heard of people with over 100K.

One thing I would make sure to do, though, hearkening back to the beginning of this thread: I would not add duplicative relationships. For instance, sibling relationships can be derived from parent-child ones, so I wouldn’t include them

2 Likes
#22

I’m now realizing that using familial relationships in my initial example may have been taken too literally. I provided the example as I figured it was one that everyone was familiar with, and I figured that I could work from whatever solution to that example was provided to solve the issues I’m having with my project. But now I’m realizing that the example may be doing me a disservice going forward as I’ve run out of analogs for future problems.

So, as a sort of introduction 1.5, I’m an archaeologist and linguist of the Ancient Near East, specializing in northern Semitic cultures during the Bronze and Iron Ages. The project I’m working on is an attempt to get ALL of my notes in one place. I’ve been trying to find a program since grad school that could handle that, and tiddlywiki is the closest I’ve ever come. That said, while I do understand the particulars of the very niche field I’m in, I don’t have any real background in data management or organization (if you go to pretty much any archaeologist’s office, you’ll realize most of us lack any organization skills outside of a dig site, lab, or museum). As a result, I’m finding myself constantly at a loss at how to handle certain data, especially pertaining to displaying relationships between different items in my notes.

And that brings me to the next part of this. While I’m 100% positive that using separate relationship tiddlers for managing certain relationships between other tiddlers is definitely the correct path for much of what I need to accomplish, I’m not sure how to create certain relationships in that manner. For instance, if I have two words in two different languages used across the Eastern Mediterranean and I wanted to create a relationship between them that showed that they were cognates to one another, I could definitely create a separate relationship tiddler for that. But what if I have three or more such words cognate to one another?

For example, let’s say we have five words (where “W” abbreviates “word” and the language of origin is in the following parentheses): W1 (Akkadian), W2 (Canaanite), W3 (Ugaritic), W4 (New Kingdom Egyptian), and W5 (Amorite). All of these words are cognates to one another, and I want to show that. I know that I could make a relationship tiddler for each individual relationship between them, but with five words, that would be ten separate relationship tiddlers. Since the relationship between them is mutual and nonhierarchical, would it be better to just create one relationship tiddler with a single field and then list the individual tiddlers like [[W1]] [[W2]] [[W3]] [[W4]] [[W5]]? Would this be the way to handle any mutual and nonhierarchical relationship between two tiddlers that cannot be derived from other relationships (as can be done with siblings by deriving them from the parent/child relationships as Scott_Sauyet mentioned above)? And if I did so, to display the cognates on each of those word’s tiddlers, would I just write a transclusion with a filter that filters out the current tiddler and then provides the rest of the list?

#23

Perhaps something like this?:

title: meaning/42
tag: Term
name: peace

Some overview in the main language of your wiki (English?) about "peace".  Or leave empty.

title: word/673
tags: Word
caption: 𐤅𐤔
lang: Akkadian

Perhaps some information here about 𐤅𐤔

title: word/8690
tags: Word
caption: שׁלום
lang: Hebrew

Perhaps some information here about שׁלום

…

title: def/232
tags: Definition
word: word/860
meaning: meaning/42

title: def/7211
tags: Definition
word: word/8690
meaning: meaning/42

This has the flexibility that one word might be tied to several different meanings. If you don’t need that, then you can replace the definition tiddlers with a single field in the Word tiddlers that points to the meaning.

Then a template for Word tiddlers can link to the appropriate Term, and a template for the Term tiddlers can list all associated words and their languages.

#24

So then using a single tiddler to tie them all would be incorrect?

With your example:

title: word/673
tags: Word
lang: Akkadian

title: word/8690
tags: Word
lang: Hebrew

plus an additional

title: word/6723
tags: Word
lang: Amorite

title: word/1123
tags: Word
lang: Canaanite

If I then had just

title: cognate/01
tags: cognates
words: [[word/673]] [[word/8690]] [[word/6723]] [[word/1123]]

and had a filter in the view template for the words themselves that would show the list while excluding itself, would that be wrong? If so, what issues could arise from that method?

I’m not really looking to tie words to separate definitions, as there is cultural nuance that would be lost. I’m just trying to show cognate terms across multiple languages and cultures. For me, simplification is everything, which is why I started with the original idea of having fields update each other in my first post here. The more tiddlers there are, the more I have to sort through, and as I’m sorting through and cataloging my existing notes from a decade+ in the field, it’s already a tedious endeavor. Anything I can do now to make it less tedious is needed, but I also want this to be relatively future-proof, should I decide to do other things with this data later. That’s why I’m trying to find the best method now, before I actually start putting it all in to the wiki.