Discussion on reasonable types of implied relationships ➞ FR: fine-tune them

[chrisgrieser]

What could be really useful would be to fine-tune the type of implied relationships to have. I tried to lay out every possibility I could think of, including the one's already implemented in Breadcrumbs for clarity. (Also using some SNA terms, since I know you know them, and since they make it a bit more clear in my view.)

---

Identity:

• A note is its own sibling (has a toggle already)
• A note is its own parent/child (not implemented at all) (SkepticMystic: I don't think I'll implement this, but good to have for completeness).

Reciprocity:
(cannot be toggled individually, but are affected by the toggle for all implied relationships)

• Sibling relationships are reciprocated
  • Implemented
  • Individual toggle
• Parent-child relationships are reciprocated
  • Implemented
  • Individual toggle
• next-prev relationships are reciprocated
  • Implemented
  • Individual toggle

Structural Equivalence:

• Having the same parent makes two notes a sibling (affect by global toggle for implied relationships)
• Having the same sibling makes two notes a sibling (not implemented at all)

Transitivity:
(none of this are implemented, often not desirable, but maybe some users find use for this?)

• A note's parent's parent will also be its parent. Same for children. (i.e. grandparent/grand-children)
• A note's siblings' sibling's sibling will also be its sibling _(not sure whether this is potentially already covered by the structural equivalence for siblings – it's basically one node step further.)
• You parent's sibling (= aunt/uncle) is also your parent. Same for nephews/nieces.
• (strictly speaking, this would also include next/prev, but I cannot really think of a use case where you want to next to a next's next, so probably this one is irrelevant 😅 )

Other Relationships?!:

• toggle to make cousins siblings? 🤔

Multiplex Structural Equivalence:

• Having the same parent, across two hierarchy types, makes two notes a sibling (has a toggle already)
• Having the same sibling, across two hierarchy types, makes two notes a sibling (not implemented at all, I think)

---

I have a certain preference on which types I would like to have, but I assume others might have different preferences, so I assume toggles for everything might make sense? 🤔

Bonus Points
Have the types of implied relationships configurable per hierarchy type 😆

wall-o-toggles!!

[scriptor-dga]

I love this! This request for a more powerful detection of implied relations has been already raised in the Discussions and Issues forums - they're among the latest topics. I only have some questions/considerations:

• The two identity ones. Can someone explain to me what's the use for these? 😅
• "Having the same parent, across two hierarchy types, makes two notes a sibling (has a toggle already)" - what do you mean by hierarchy types and where is this toggle? Isn't this the same as "Having the same parent makes two notes a sibling"? Maybe you could explain it with a little drawing? 😀

[SkepticMystic]

Thank you for the effort here, I really appreciate it!
I definitely agree that it would be very useful to be able to toggle specific relation types. I'll implement this when I can.
One question, why would a note be its own parent/child?

[chrisgrieser]

@SkepticMystic That one I mad mostly for consistency, since you already have "Note is it's own sibling". Not sure whether it makes sense though 😅

Btw, I made a small edit adding some stuff

[scriptor-dga]

@SkepticMystic That one I mad mostly for consistency, since you already have "Note is it's own sibling". Not sure whether it makes sense though 😅

Btw, I made a small edit adding some stuff

What do you mean by hierarchy types? 😁

[chrisgrieser]

@SkepticMystic okay, I updated even more 🤣

@scriptor-dga you can add more hierarchies than just up/down/same/next/prev https://github.com/SkepticMystic/breadcrumbs/wiki/Hierarchies

[SkepticMystic]

@chrisgrieser I'm gonna be editing your post to keep track of what I've implemented so far (the changes aren't publicly available yet, but it's a big project to keep track off)

[scriptor-dga]

@chrisgrieser I'm gonna be editing your post to keep track of what I've implemented so far (the changes aren't publicly available yet, but it's a big project to keep track off)

Do the betas include these changes already? Do you have a link?

[SkepticMystic]

@scriptor-dga you can play around with it by manually installing from here.
But the new implied relationships haven't been added everywhere. So you might see them in the createIndex results, but not the matrix view, for example

[mikkovedru]

I want to add some thoughts and considerations about the transitivity aspects.

I assume and will comment from the POV of taking the idea to the logical conclusion. Meaning that it's not just about increasing the depth of the implied connection generation by one, but about following the graph until the very end, until all the real connections are processed, all the implied connections are built, this is done iteratively until the whole group is stabilized.

1. "A note's parent's parent will also be its parent. Same for children."
   • I can't come up with any good example which would need this.
   • Generally speaking, this is useless. If we assume that all the notes are participating in the Breadcrumbs graph in one way or another, it means that logically/algorithmically ALL the 100s/1000s of notes in the vault are going to be in 3 categories: up, same or down. Each category will have hundreds/thousands of entries making it useless (both to display, to use and get any benefit)
   • This is also contradictory in the sense that the algorithm is not deterministic. Meaning that we can get different results depending on the order in which independent steps/implications are made. Example.
     - Real connections: Me -(up)> Dad, Dad -(up)> GrandDad, Dad -(same)> Uncle, GrandDad -(down)> Uncle.
     - Algorithm1. Since Me is GrandDad's implied down-down, it means that Me becomes GrandDad's singular down. Which means that Me becomes at the same level as Dad and Uncle.
     - Algorithm2. Since GrandDad is Me's up-up, it means that GrandDad becomes my up, together with Dad. And from here, via GrandDad's down connection we imply that Uncle becomes Me's same (while still staying Dad's same?). An unsolvable contradiction.
2. "You parent's sibling (= aunt/uncle) is also your parent. Same for nephews/nieces.".
   • This also seems to have a lot of problems. It's hard to see any value in it.
   • This is also totally algorithmically incompatible with the previous point 1.
   • Actually, as well as by itself, akin to the previous examples I gave.

Basically, the whole concept just implodes as soon as we start messing with the up/down connections. Mathematically, algorithmically, UI-wise, in convenience, in usefulness.

But here is the great news. I think that those features are not even necessary/needed in the real world.

One of the core problems is the conceptual/linguistic ambiguity in what we mean by words like "up" or "next". They can mean 2 different things:

1. Meaning1. The very next in "up" or "same/side". If we are on the floor 3, only the floor 4 can be "up".
2. Meaning2. Just a general direction of "somewhere up" and "sometime next". All the upper floors (4, 5, 6, 10, 15, etc) are "up" from us.

If you agree with me about the issue with messing with the up/down connections, that Breadcrumbs should not implement them, then all the unsolvable problems go away.

But that still leaves us with the core problem of ambiguity with what "next" and "prev" mean and how they should be processed.

1. Both meanings can't be correct - they are contradictory. We have to choose only one.
2. One of the 2 Meanings can be chosen as canon and we go with it. But any of the choices will have their own set of challenges (both technical and usability/usefulness-wise).
   • For example "(strictly speaking, this would also include next/prev, but I cannot really think of a use case where you want to next to a next's next, so probably this one is irrelevant sweat_smile )" is correct only if "next" would have Meaning1. But it is very much a needed feature if Meaning2 is the one that it's decided to go with.
   • There is an issue of what we mean by "same" and how does it fit in the whole picture.
3. Perhaps those 2 meanings can be separated by creating 2 new categories. Something like "generally prev", "immediately prev", "immediately next", "generally next". Obviously, we should try to come with better names. :-)

My vision/solution

Now that I unloaded a set of problems on you, let me also provide my vision of the working solution.

1. Forget about messing with up/down connections. In no way should "Germany", "Pyramids", "Machine Learning", "hoaxes" and "tigers" be in the "same" category despite being the same distance from the top category of Earth (via countries, constructions, technology, history, animals). If we start ignoring levels (and kinda would have to), this will lead to unsolvable logical/non-deterministic problems.
2. We should still keep "same" and "prev/next", because they should represent different ideas. The former should indicate a looser group, while the latter should represent a more organized and tightly-coupled group.
   • Imagine "step-sibling" and "sibling".
   • or Me "Harry Potter 2 book" with up being "Fantasy books", same being "Hobbit", and next being "Harry Potter 3 book".
3. Basically, if any items are connected by prev/next (real or implied), the whole group of notes should be considered tightly coupled. If the only connection between a note and any other notes from the tightly coupled group is "same", then they represent different groups.
4. There can be any amount of groups. Any amount of tightly-coupled groups plus all the independent non-tightly-coupled notes should be considered their own separate groups (instead of putting all the single items together).
5. I think that "prev/next" should be solved by either of 2 choices:
   1. Create 2 new categories for prev/next like I described earlier
   2. Choose the Meaning2. This may look like a worse decision than taking the Meaning1, but it is so only on the surface. Sure, Meaning2 would mean walking the whole graph, calculating all the connections and figuring out the missing connections and their order, while with Meaning1 we could just say "it's user's job to make sure that all the notes are properly linked, in correct order and with only one prev/next link respectively; algorithms will not help you". It will not be obvious nor convenient, users will be confused, but we can always gloat in righteousness and show users a lot of FAQs. :-) But if you take into account the fact that there can (to increase convenience and usability) be more than 1 prev and 1 next link in each note, it quickly becomes clear that Meaning2 is the way to go. I can expand on this idea if you need.
6. Imagine that I have 1000 notes about films and I found the Breadcrumbs plugin. I want to start using it.
   • Meaning1 would mean that I have to go through all the notes, carefully marking which films follow which. Until I do that careful work, the categorization is unusable. Even though I most probably don't need the extreme precision, at least not in the beginning. The required work-load is massive.
   • Meaning2 would mean that I can take it way easier. I can just loosely throw all the Harry Potter films together in one tightly-coupled group, all the Terminator films in another, while leaving the rest be (some grouping can be done, but I can't be bothered at this point). This is a great thing to minimize the amount of effort needed to begin and start receiving benefits.
   • My point is that people might be after the tightly-coupled group functionality of the prev/next associations, to have a sort of sub-groups among siblings, without necessarily needing to have the functionality of the tightly ordered list. This is not a bad thing.

I hope my novel made sense (I am too tired to edit it at this 4:30am point of the night). 👍

[scriptor-dga]

I back what mikkovedru says and I also have a question: did you add the relationship "if A is child of B and C is sibling of A, then C is child of B"?

[HEmile]

I have also been thinking a bit about this FR. I think that toggling these implied relationships by type of relationship does not make much sense. Rather, it should be an attribute of the field/type of relationship.

Example: Consider the types partner and same. I'd model both of these as <-> relations (something akin to equivalence). Now consider the new kind of implied relations that can be formed from these:

Transitivity:

• A -> partner -> B && B -> partner -> C
  • Then also A -> partner -> C
• A -> same -> B && B -> same -> C
  • Then also A -> same -> C

Transitivity clearly holds for the same relation, but this isn't always the case for the partner relation (consider a polygamous relation where this holds).

---

To some degree I agree with @mikkovedru too. I don't much see the value of adding implied transitive connections for up/down relations, and especially not for uncle/cousin relations. The full hierarchy formed from up/down relations can already be inspected by the views Breadcrumbs provides (for instance the down view, code blocks, and the Juggl view in the new beta release). Rendering those views using the implied graph would be very messy with a lot of connections.

[BricoleurSoul]

You may recall my earlier comments on the usefulness of leaving the preponderance of most implied relationships as exactly that (rather than forming the link in real mode in both directions). It is so useful to be able to have both types show up in the matrix - it allows pinpointing  the most critical connections out of large groups of matrix entries quite easily. I’m afraid the  proposed changes could prove to be  an exercise in “making EVERYTHING LOUDER than everything else”  —  and so not merely  messy,  but with everything claiming to be of equal importance, the “cacophony” could be the death mill of efficacy of breadcrumbs (and ultimately make it no more useful than dataview code showing every link in and out of every given node… and yes, I’ve been there, done that and still have it in place for my yet to be breadcrumbed entries!) Please, please advance with caution on this one! Bricoleur

…

On Jan 17, 2022, 12:50 AM -0800, Emile van Krieken ***@***.***>, wrote: I have also been thinking a bit about this FR. I think that toggling these implied relationships by type of relationship does not make much sense. Rather, it should be an attribute of the field/type of relationship. Example: Consider the types partner and same. I'd model both of these as <-> relations (something akin to equivalence). Now consider the new kind of implied relations that can be formed from these: Transitivity: • A -> partner -> B && B -> partner -> C • Then also A -> partner -> C • A -> same -> B && B -> same -> C • Then also A -> same -> C Transitivity clearly holds for the same relation, but this isn't always the case for the partner relation (consider a polygamous relation where this holds). To some degree I agree with @mikkovedru too. I don't much see the value of adding implied transitive connections for up/down relations, and especially not for uncle/cousin relations. The full hierarchy formed from up/down relations can already be inspected by the views Breadcrumbs provides (for instance the down view, code blocks, and the Juggl view in the new beta release). Rendering those views using the implied graph would be very messy with a lot of connections. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SkepticMystic]

This has become quite an interesting discussion, indeed.
I see the points each of you are making.
I'm going to keep thinking about this before deciding how to act.

I will say this for now:

• I agree that not all of the proposed relations should be implemented.
• Any new relations that are added will be purely optional. There will be more fine-grained control over relations than there currently are. It also won't be a breaking change - Breadcrumbs won't behave differently if you don't enable the new relations.
• There are certainly some challenges that arise when pondering some of the relations. Some practical, like the non-determinism, some more philosophical. The arguments made are good, so I'm going to take some more time to think about this.

Please do continue discussing, I really appreciate the thought that is going into this :)

[mikkovedru]

Here is another topic that requires (re)thinking. This is an apt place and company to discuss it.

Currently, the relationships Breadcrumbs define can be described as structural. It defines which note is:

• bigger/smaller than the current one (current's parent/child), that the current one is fully part of or partly represented by. Example: Animals -> Mammals (current) -> Tiger
• same. Iron <-> Copper <-> Titanium
• prev/next. Chapter 1 -> Chapter 2, Chapter 1 <- Chapter 2

This is a logical and useful way of thinking and organizing notes. But this is not the only possible one. Another one could be logical as in "what leads where", arrows of thought, of a cause and effect. It can be thought of as a directional mind-map. Or a flowchart (mermaid, supported in Obsidian), but for notes.

The tricky thing is to decide what each current relation type means in this logical-flowchart system, if some of the types should be renamed, removed or added.

For example Liger (a hybrid offspring of a male lion and a female tiger). Which relation should be used between those 3:

1. parents-child
2. same-same
3. prev-next?

I guess it depends on the situation and what one wants to achieve with the particular note system? This definitely needs more thought.

Understanding what I mean will require some time and brain effort, because of the confusion since the current system can also in some way be described as logical (it is indeed logical that "Chapter 1" is the child of "Book X").

I haven't had enough time to go all the way to the depth to think about this idea, what it entails and to decide on my own logical and publicly defendable position. Or even to decide if it is useful enough to spend energy implementing. I guess my current position is a careful "Might be useful. Implementation-wise, in my workflow I would like to have a per-directory control of which style of Breadcrumbs to use.".

Thoughts?

Edit:
The important thing to understand about the flowchart is that the movement/connections/arrows are going in all kinds of directions - not just from top to the bottom. There can easily be a closed circle of 3 notes/ideas in which every note is both a parent and a child. Or a situation in which the flow can go either way (rich -> famous; famous -> rich).

[andrey-jef]

Just have learned about this discussion. I'm curious to learn what are the trade-offs if we use namespace to imply the relationship; i.e. parent, parent.child, parent.child.grandChild?

Pros:

• With namespace, the siblings-relationship and parent-child relationship can be explicitly applied, without the needs of "hierarchy note" or key in frontmatter

Cons:

• can not express the next-previous relationship
• exclude the case "Having the same parent, across two hierarchy types, makes two notes a sibling"

[SkepticMystic]

All the implied relationships I intend to implement have been added, I believe.
Thanks everyone for the discussion, gonna close this out