expand_less
whoops, this is a duplicate. Let's import the best stuff from the old idea here (closing the other one):
{{implement bidirectional relationships|closed}}
1-3 are explorations of the "one approach" (see top of solution). 4 is a different approach, no?
--[[Ethan McCutchen]].....2015-05-01 23:15:18 +0000
Yeah, it is more like creating a join record in ORM. I think it might make sense when we actually are using the *type_plus_type pattern as in wiki-rate extensions. So, I guess it really needs a second thing at the top level.
But it does illustrate the concept of linking via namespace (+). It isn't how we typically use the + relationship.
--[[Gerry Gleason]].....2015-05-02 15:12:49 +0000
Thanks for putting forward the "another solution" (type+type). Definitely worth digging into. It's come up a few times, and I've always been uneasy about it, but it's worth deeper exploration. I'm guessing you're in the same boat (not advocating yet but wanting to explore?)
To me, it has several issues that would need working out. The first is the nature of relationships.
Let's say we have three companies: Holding Co, Producer Co, and Retailer Co. What does the existence of Producer Co+Retailer Co actually tell us? (In the Pointer-Search, the pointer name is meaningful, and in fact we could put +subsidiary, +client, +franchisee, _whatever else and represent multiple company-to-company relationships). We could put something in the content, but how would we distinguish between unidirectional and bidirectional links?
I should probably clarify that "bidirectionality" might be a confusing word here. In this use, it's not really about the nature of the relationship, but about the interface. Eg, we're not talking about distinguishing between A loves B, B loves A, both, and neither. We're talking here about whether you can *edit* the fact that A loves B from both A and B.
To my mind, the Pointer / Search pattern gives us pretty good coverage for representing of standard relationships. As you have pointed out, pointers are, by default, many to many. We need some good patterns for restricting that, but it's kind of an awesome starting place.
Do you agree that with pointers/ searches, most relationship patterns are easy to represent in data, even if difficult to update? Perhaps I should change the name of this ticket to "support bidirectional editing"?
--[[Ethan McCutchen]].....2015-05-03 21:26:18 +0000
In any case, unless we think we want to get rid of the pointer-search pattern, we will very likely want to be able to edit the relationship from the search side. I suppose the question whether that discussion should happen here or elsewhere depends on how much we think we want to invest in other relationship representations.
--[[Ethan McCutchen]].....2015-05-03 21:30:12 +0000
see also [[Relationship Card]]
--[[Ethan McCutchen]].....2015-05-04 20:06:16 +0000
whoops, this is a duplicate. Let's import the best stuff from the old idea here (closing the other one):
{{implement bidirectional relationships|closed}}
1-3 are explorations of the "one approach" (see top of solution). 4 is a different approach, no?
--[[Ethan McCutchen]].....2015-05-01 23:15:18 +0000
Yeah, it is more like creating a join record in ORM. I think it might make sense when we actually are using the *type_plus_type pattern as in wiki-rate extensions. So, I guess it really needs a second thing at the top level.
But it does illustrate the concept of linking via namespace (+). It isn't how we typically use the + relationship.
--[[Gerry Gleason]].....2015-05-02 15:12:49 +0000
Thanks for putting forward the "another solution" (type+type). Definitely worth digging into. It's come up a few times, and I've always been uneasy about it, but it's worth deeper exploration. I'm guessing you're in the same boat (not advocating yet but wanting to explore?)
To me, it has several issues that would need working out. The first is the nature of relationships.
Let's say we have three companies: Holding Co, Producer Co, and Retailer Co. What does the existence of Producer Co+Retailer Co actually tell us? (In the Pointer-Search, the pointer name is meaningful, and in fact we could put +subsidiary, +client, +franchisee, _whatever else and represent multiple company-to-company relationships). We could put something in the content, but how would we distinguish between unidirectional and bidirectional links?
I should probably clarify that "bidirectionality" might be a confusing word here. In this use, it's not really about the nature of the relationship, but about the interface. Eg, we're not talking about distinguishing between A loves B, B loves A, both, and neither. We're talking here about whether you can *edit* the fact that A loves B from both A and B.
To my mind, the Pointer / Search pattern gives us pretty good coverage for representing of standard relationships. As you have pointed out, pointers are, by default, many to many. We need some good patterns for restricting that, but it's kind of an awesome starting place.
Do you agree that with pointers/ searches, most relationship patterns are easy to represent in data, even if difficult to update? Perhaps I should change the name of this ticket to "support bidirectional editing"?
--[[Ethan McCutchen]].....2015-05-03 21:26:18 +0000
In any case, unless we think we want to get rid of the pointer-search pattern, we will very likely want to be able to edit the relationship from the search side. I suppose the question whether that discussion should happen here or elsewhere depends on how much we think we want to invest in other relationship representations.
--[[Ethan McCutchen]].....2015-05-03 21:30:12 +0000
see also [[Relationship Card]]
--[[Ethan McCutchen]].....2015-05-04 20:06:16 +0000