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

#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.

#25

No, not at all. I was mostly just following through on the notion I introduced earlier. The only run-time difference I can see is that when looking for cognates for a word, you will need to search through a list field rather than a plain field. There are tools for this, and I wouldn’t worry about it. You can still handle the possible multiple cognates for a word with this if you wanted them. I feel as though there might be additional flexibility with my suggestion, I can’t actually see any reason why right now, so it might be just a matter of my hammer looking for a nail.

1 Like
#26

I wonder myself if a relationship table full of one to one relationships, partnerships but each relationship has an optional start/end date and a relationship type field. Defaco, Business, Marrage …

  • If a title like husband or wife can be determined else where one may need to add a “known as” for each side of a relationship type.

@Ryan_Quinn have you looked at marios alias plugin? This can help something have more than one name, and you could always add more info through additional tiddlers.

1 Like
#27

You certainly could. There’s a major tension between wanting to group any such relationships into a common format, and wanting custom handling for your various types. I’ve seen large-scale systems to deal with application reference data that uses a single generic SQL table, with a type field, and for each type, records in a mapping table of how a field maps to one of the generic column names. It’s touted for its flexibility. But it’s also inflexible in various ways. The point, though, is it doesn’t take DBAs’ time to add a new reference table; any business analyst or programmer could do it.

I don’t think I would choose it for my TW projects. Here I prefer the type information in a tag rather than the combination of a generic tag and a relation-type-field. But it’s clearly a reasonable way to go. The big advantage of doing this in TW over SQL is that you wouldn’t need a fixed list of fields. One tiddler might look like:

title: rel/171
tag: Relationship
rel: marriage
person1: person/8675
person2: person/309
wedding-date: 1990-06-09

and another might look like

title: rel/652
tag: Relationship
rel: parent-child
parent: person/128
child: person/317
#28

I wonder though if we could make a generic tool that helps support the idea of intermediate index tables, with relavant fields added to relink to maintain referential integrity. Thus bring the idea of a relationship into TiddlyWIki as a generic tool.

  • Perhaps we coulfd then associate specific fieldnames with a relationship type in that index.
  • We do however need to permit missing values as real life does not always know everything.
  • The tool would allow its use without the skill level currently needed to build relationships.
  • We may also conside one to many and many to many relationships as well (perhaps via tags)

I could imagin a tool that allso ask the user if they know missing information.

  • eg; Jill is married but we dont know to whom, since when.
1 Like
#29

If you’re serious about pursuing this, you might want to look at the Resource Description Framework, which deals with such relations in a uniform manner.

#30

Interesting. I was once a Database administrator so know my normalisation etc… but an initial review of this doco made me think of hybridising it with another solution I value, the idea of fields whose content has a protocol prefix eg https:// which then becomes a link when referenced, or alternatelly the one protocol is implied for a specific field eg *-link fields, the url field - contain link related protocol eg https://

Now consider if the same existed but for relationships eg; defacto:title or a field marked as defacto need only contain title

  • permit empty values
  • permit multiple titles (list field)
  • defacto:[[title with spaces]] [[a second defacto title]]

the idea is to define our own protocol set based on the relationship types in an index.

I have being playing games with using the pretty name when one is not needed eg; [[defacto|person title]]

#31

I love questions like this! :grin:

You’ll know whether this makes sense, but my hunch is that there’s generally a likely flow of influence in the big picture. For example, cognate words exist in a bunch of European languages because of Latin, or because of Proto-Germanic (etc.). A bunch of Japanese words arrived from China, and not much (in deep history) flowed the other way…

If this hunch works well for your world of research, I’d consider informally modeling a rough influence-cascade of languages, so that a research-tiddler for the word from the historically earliest (and/or culturally most influential) language (among any batch of cognate words) serves as the “home” for the cognates field that lists the others. All words in a cognates set display the same inter-linked set of references, even though one record serves as the home.

(It doesn’t really matter for this purpose whether the influence-flow really always goes this way — it’s just a rule of thumb that might help you have a non-arbitrary way to feel oriented to where to add the cognates info, which is then displayed in all related records… Sorta like my accountant having the practice of always archiving joint-tax-filing-records under the husband’s name, if there is a husband. There isn’t always a husband, and husbands aren’t really being affirmed as more important for taxes or anything else; it’s just his own quiet albeit old-fashioned first-rule-of-thumb, while someone else might default to the spouse whose name comes first in alpha order, etc… :wink: )

If you suddenly find that an older variant/cognate exists, no harm done, just migrate your list to that tiddler (or just shrug at having an exception to the rule-of-thumb for where things “live” under the hood (to mix metaphors!).

Maybe you’d even want an expansive related.words filter that treats anything that turns out to be listed as a cognate of something that’s listed as a cognate… Displaying this expanded list may help make you confident that you’re bridging any unexpected sprawl in the what-got-entered-how department).

I do think TiddlyWiki is a fantastic tool for research. This is largely because you don’t need to know all of your structure before you get started. TiddlyWiki opens up like a Bag of Holding. Of course, thinking in advance about structure can be a nice favor to your future self! But with a tool like Commander, you can still do some cleaning-up or refactoring down the road (if you want to take all records with a certain naming-pattern and set up a certain field or tag for them, or vice versa, etc.).

Cheers! Please keep the questions coming as you’re finding your way!