PowerStructures

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Various possible power holders and relationships used to consolidate and wield power are listed below. Special relationships are listed in parentheses on the right.

You got it. This is/was preliminary notes for CrystalPalace.

Person (family, sexual, friend, employee, employer)
Private corporation
Public corporation
Zaibatsu [WhatIsaZaibatsu]
Non-governmental organization
Charity (Power holder-->benefactor, Charity-->beneficiary)
Templar
Government
Consortium
Committee
Intergovernmental association
Trade union see LaborUnion

Generalized relationships

This is a list of relationships that all power holders may have with each other.

(Partial) Owner
Contract
Alliance
Memorandum of Intent
Enemy
Competitor
guanxi (a long-term reciprocating relationship)

One useful way to organize such relationships is by cooperation like:

Self (internal relationship)
Owner (controlling owner)
guanxi (a long-term reciprocating relationship)
Alliance
Contract
Memorandum of Intent
Non-aligned (a neutral sense, like a business in a different field)
Competitor
Enemy (acts against your interests even if it hurts them)

The more I think about it, the less I'm comfortable providing only a restricted set of relationship and entity types for CrystalPalace. Humans have many, many types of each. However, I would like to make it possible to do strong data mining, which requires structure. Freeform text vs. restricted list. This is a big problem for me. Ideas would be welcome. -- SunirShah

: H'm. Not sure I have any ideas, per se. But rambling on about this is sure to get us closer to a deeper understanding. Plus it's fun.

: A lot of relationships generally entail other relationships. I'll use family as an example. For example, at least for the overwhelming majority of marriages, "marriage" => "sleeps with" (a relationship I just saw on your CrystalPalace test script). Generalizing further about family roles of husband:wife, or parent:child is difficult since the understanding of family varies so widely (and for some people, family may not even imply husband:wife). Nevertheless, there are typical power relationships, especially when it comes to parent:child.

: It's interesting, also, in that the relationshpis are very mutable. Consider the parent:child relationship. A baby is nearly helpless without someone to care for it, but as the child grows, it gradually becomes more independent, until at some point it becomes its parents' peer. (Not all parents choose to recognize this. H'm. . . Maybe for each relationship there should be three models: one for how party A perceives the relationship, one for party B, and one for outside observers. Not even all outside observers will agree, however.) Examples of this can be seen in the business world. Consider IBM and Microsoft's erstwhile partnership and where they stand now. Or IBM and Apple's long-standing collaboration on Taligent that ended up languishing. (Sigh.)

: If you want to model the full spectrum of relationships, it must capture these two facets: relationships are mutable over time, and relationships have a fuzzy aspect that makes them individual entities all to themselves. No relationship is entirely of one type or another; a relationship exhibits differing degrees of each type of relationship.

: Business relationships are particularly interesting. While technically they are relationships between two individual entities, the individual personalities that make up each business play crucial roles in the acting out of that relationship. While two businesses may have a strong partnering agreement, personality differences between key players in that agreement may make or break the implementation of the deal. In extreme cases it may be the difference between the businesses continuing as partners or growing into enemies. Small-scale relationships influencing large-scale relationships. The same is true of relations between countries; consider the assasination that sparked WorldWarI?.

: I'm not sure how this time-mutability and fuzziness convert into a model of relationships. However, I do think you'll have to go beyond simple relational modeling to capture the essence of relationships. I'm not sure I can come up with anything compelling, but I'll think about it off and on. -- anon.

My favorite idea is "why not both? (freeform and restricted relationships)" One might recommend a limited set whenever possible, but also add additional freeform relationships whenever they seem appropriate. If a specific freeform relation becomes highly useful, it could be added to the formal list. Indeed, a useful way to start the project might be to have no formal relationships defined, and see what common ones are actually used by the users. (This is similar to the idea of letting people walk across an unpaved open space, then paving the paths where people actually walk, rather than predesigning a set of walkways that may not fit people's needs.)

The biggest thing to watch out for is that the CrystalPalace project doesn't turn into "the database of everything" (all possible relationships and information about all possible entities). If it can handle everything, then it probably won't handle any specific thing very well. It might be useful to spend some time thinking about what your project will not handle. --CliffordAdams

Another solution is to let the text be freeform but let the community self-constrain. However, this will require some sort of intrinsic advantage to consolidating the descriptions or else there would be no goal to rally around. I'm also thinking that instead of using very short relationship descriptions, perhaps a paragraph style may be more appropriate to describe the history and quality (which Scott rightly brings attention to above). Perhaps both: a relationship class and a relationship description. -- SunirShah

PowerStructures

Discussion