multiple parents for an organization

[paultag]

currently we have a parent_id key, which is great. Love that bit.

It would be nice, however, to express things like Joint Committees as having two parents - each chamber of the Legislature.

Names that come to mind: parent_ids, or a full parents list (with minimal organizations inline, likely id and name)

Thoughts?

[boblannon]

I'd like to add, too, that this would make the spec friendlier to the crazy structural relationships that appear in corporate world.

[paultag]

https://github.com/opennorth/popolo-spec/issues/41 related

[jpmckinney]

One option is to mark a joint committee as a child of the two chambers. However, since joint committees are always the children of all chambers, they are in some ways committees of the full legislature. So, it would not be inaccurate to make their parent the legislature. Are there disadvantages to marking joint committees as having the legislature as their parent?

@boblannon Can you describe a specific example from the corporate world?

In the case of a company having multiple owners with different shares of the company, for example, I think we would want a new class to express that ownership relation, rather than using the parent_id hierarchy. There may be different cases where multiple parents makes sense.

[boblannon]

Yeah, this is certainly going to need to be motivated by real-world examples. Although I've been assured by some domain experts that they exist (especially in the dark corners of dark money spending), finding specific examples will take a bit. I'll post them when I find them, however.

[akuckartz]

+1 to "make the spec friendlier to the crazy structural relationships" and for "real-world examples"

[jpmckinney]

@akuckartz If you've got examples of crazy relationships, that'd be great!

[paultag]

The only downside is it starts to feel (structurally) like it's a peer organization to the legislative bodies, rather then an organization who's serving directly under both chambers, and derives all of it's authority from.

I'd really love to set parent to both chambers rather then the legislature (which is what we're doing now)

On Mon, Jul 21, 2014 at 4:15 PM, James McKinney notifications@github.com wrote:

@akuckartz https://github.com/akuckartz If you've got examples of crazy relationships, that'd be great!

— Reply to this email directly or view it on GitHub https://github.com/opennorth/popolo-spec/issues/65#issuecomment-49659120 .

:wq

[akuckartz]

For those who can read German. This might be relevant: https://github.com/OParl/specs/issues/245

It is about joint meetings of committees each belonging to separate legislative bodies. But joint committees of several legislative bodies are also mentioned.

[jpmckinney]

@paultag Okay, I'd like to collect a few more use cases to increase the likelihood that the solution works for all multi-parent cases and not just the "joint committee" example.

[paultag]

OK, sure

Another example:

The car manufacturing organization "NUMMI" was a joint venture of both GM and Toyota, which produced cars labeled as both "GM" and "Toyota". A personal favorite.

On Mon, Jul 21, 2014 at 4:46 PM, James McKinney notifications@github.com wrote:

@paultag https://github.com/paultag Okay, I'd like to collect a few more use cases to increase the likelihood that the solution works for all multi-parent cases and not just the "joint committee" example.

— Reply to this email directly or view it on GitHub https://github.com/opennorth/popolo-spec/issues/65#issuecomment-49663105 .

:wq

[jpmckinney]

In the case of joint ventures it is generally an ownership relationship. For example, in MillerCoors, SABMiller owns 58% and Molson Coors owns 42%. While Sony Ericsson existed, it was 50% each. NUMMI also seems to have been 50% each. In the case of companies, the simple "multiple parents" approach (which for joint committees could just mean changing parent_id to allow an array of IDs) is insufficient. You'd need to at least be able to model the percentage ownership / control in the case of companies. This means introducing a new class, since we need a new container to hold that property.

Edit: A relevant Wikipedia article on parent companies suggests that by most definitions of "parent company" there can only be one parent company. In the case of joint ventures (50-50), by the same definitions, it would seem that neither is considered the parent. So, I would prefer to maintain the semantics of "parent" as-is, which is consistent with these definitions, and to introduce a new "Holding" or "Share" class that can relate companies to shareholders (in most use cases, only major shareholders will be serialized) when those relationships are relevant.

For joint committees, would it be fine to add "array" as a valid type for the parent_id property in the JSON schema, for the relatively rare case of joint committees in legislatures?

[tmtmtmtm]

Modelling ownerships as a percentage is a minefield. No-one ever directly owns a % of a company — they own a number of shares in the company, which at a given a moment will translate into a certain percentage, but can vary based on the number of shares issued (even when the holder's shareholding itself doesn't change). If the idea here is to simply model simple large-scale holdings like the examples above, then percentages might be a useful short-cut, but it'll start getting very complex very quickly (especially if you want to start tracking historic values.)

[jpmckinney]

Many disclosures only state percentages, so the model will have to allow that data to be serialized. More detail is better, but one of the principles of this project is that real-world data is often imprecise or uncertain.

[boblannon]

I agree. The idea of corporate control is actually much more complicated than this, and there are differing but equally reasonable definitions of what constitutes control. Furthermore, there are no "official" criteria to look to in most countries outside of General Accounting Practices and broad guidelines from regulators. OpenCorporates had a fantastic four-part series on this: http://blog.opencorporates.com/2013/10/16/understanding-corporate-networks-part-1-control-via-equity/

In fact, the more I think about it, representing control may be difficult or unwise to do in a model-internal way. It would probably be more useful to have an external series of edges between org nodes that describe things like ownership, control, etc. Then the hierarchical structure could be derived on-the-fly given the requester's methodology wrt what constitutes a parent-child relationship. On Jul 22, 2014 12:23 AM, "James McKinney" notifications@github.com wrote:

Many disclosures only state percentages, so I expect the model will have to allow that data to be serialized. More detail is always better, but one of the principles http://popoloproject.com/ of this project is that real-world data is often imprecise or uncertain.

— Reply to this email directly or view it on GitHub https://github.com/opennorth/popolo-spec/issues/65#issuecomment-49696769 .

[jpmckinney]

To resolve @paultag's issue, I think the best and simplest solution is to allow parent_id to be an array. Would that work for you, Paul?

To resolve the other issues brought up in this thread relevant to corporate hierarchies/control, I think a new class would need to be introduced to represent the edges that @boblannon describes. I will open a new issue for that once we resolve this one.

[jamesturk]

The more we've talked about this the more we've sort of come around to the idea that the simple case of just an array of parent_ids isn't something we need, if/when we need to model the more complex relationships something that is geared in that direction would be needed anyway so there's probably no reason to complicate things w/ a parent_id array for now. /ccing @paultag in case I misrepresented anything, but I think our vote is to retract our request for multiple parent_ids in favor of waiting for a future solution

[paultag]

Yeah, I think I didn't completely think through the relation. As we talked about it more, it became pretty clear that it would add a lot of complexity that didn't really get us anything.

Yeah, I'm OK closing this without changes to Popolo. Sorry about that.

[boblannon]

Don't be sorry. I'm happy it was discussed!

[jpmckinney]

Indeed, this discussion helped clarify many issues. I've expanded #56 with a note of this discussion where we can continue exploring corporate hierarchies, and where we can pick things up if/when more complex relationships need to be modeled. Thanks!