Add property to relate a membership to a legislative term

[jpmckinney]

proposed name is legislative_period. legislative_session would match Motion and VoteEvent, but since we generally intend to use the property to refer to a legislature/parliament and not a session, it would be confusing.

[tmtmtmtm]

What would the disadvantages be of making a separate Organization for "113th US Congress", "114th US Congress" etc?

[jpmckinney]

How would you collect all the congresses - would they be suborganizations of "Congress"? And each Congress would have the House of Representatives and Senate as children?

[tmtmtmtm]

I'm not sure yet — probably something like that (I haven't really thought it through for bicameral legislatures). It just seems like this way might adequately reflect reality and provide simpler querying (both for the standard "Who was a member of the XIIth Riigikogu?", and perhaps also for the "Who left the 113th Congress before the end of the term?") without needing any new terms.

It might still be better to add something to do this more explicitly — I'm just exploring an idea here.

[jpmckinney]

I think having multiple Houses of Representatives and Senates - one for each Congress - would be odd; the only thing distinguishing them would be their parent organization. You can inverse the hierarchy, and instead have two of each congress - one for each of the House and the Senate - but that is also strange. Note that US Senators are elected to 6-year terms, but congresses only last two years.

In the US case, "who left before the end" is easier to answer without requiring a reference to terms, since elections follow a schedule, unlike legislatures with votes of confidence.

Anyhow, if not adding a new term, I think "Who was a member of the XIIth Riigikogu?" should require knowing the start and end dates of that term, and then just comparing those with the dates of memberships of the legislature. The membership doesn't need to reference the event.

[tmtmtmtm]

The specifics of how to model it aside, I'm unconvinced by the approach of needing to know the dates to be able to query who was a member — that seems like a rather odd level of indirection for what will be a very common query.

As a slightly lesser issue: this approach would also eliminate a lot of needless duplication of dates: there wouldn't need to be start_dates and end_dates on each individual Membership of the XIIth Riigikogu, for example, if it were a thing of its own. These would only need to be provided on each Person's Membership if they joined late / left early. Partially this one is just my inbuilt dislike of repeating information — fixing a mistaken date for when a legislative term began should really just be a single change, rather than hundreds. It also seems plausible that, particularly when dealing with historic information, we may not actually know the dates of terms.

[guglielmo]

I'm facing similar problems with the Italian Parliament, which is bi-cameral, with synchronized chambers.

I wouldn't use such a property, but would rather model different organization instances, each related to a given term. And keep a base organization, to reach them all, if need arises.

For the Italian Parliament use case:

[jpmckinney]

@guglielmo After discussing last week, do you agree it would be simpler to have:

• 1 Organization (Parlamento Italiano) with:
  • 2 suborganizations (Camera and Senato)
• 1 Event per term (e.g. Parlamento XIV)

And then, relate a membership to the correct Organization (e.g. Camera) and Event (e.g. Parlamento XIV).

Instead of having:

• 1 Organization (Parlamento Italiano) with:
  • 1 Organization per term with:
  • 2 suborganizations (Camera and Senato)

And then relating a membership to the correct suborganization (e.g. the Camera child of Parlamento XIV).

The difference in complexity is having 2 organizations for the two chambers versus terms × 2 organizations for the two chambers.

[guglielmo]

Well, yes, it's certainly a simpler model that comes out.

[jpmckinney]

In my comparison of the two options, I forgot to add that the first option adds a new class (Event), so it's adding complexity in a different way. But if we're all agreed on following the first option, then I can proceed with it. @tmtmtmtm You initially asked about the disadvantages of the second option. Do you also prefer the first option?

[guglielmo]

From the Popolo standard's perspective this is not a problem. But if I think in terms of the existing components, then I guess Popit should be changed, to model Events as first class objects, as embedding them into each Membership would be rather unpractical.

[jpmckinney]

I've started a PopIt issue: https://github.com/mysociety/popit-api/issues/142

[tmtmtmtm]

@jpmckinney how do you see this working for modelling the Government side — Cabinet positions etc?

That seems like it would raise a lot of the same questions as the legislative side...

[jpmckinney]

Couldn't it be done identically? Perhaps I am missing some context on what makes it a special case.

[tmtmtmtm]

I'm not sure. In the previous discussions about things like this it's always been assumed that it'll be a separate Organization (e.g in modelling a coalition), and I'm just starting to think through all the knock-on implications. As always the question isn't how could this be done, but how it should ideally be done in a way that facilitates tool reuse etc.

I also don't know enough about all the different systems out there to know, for example, what different relationships exist between the different elements in practice.

In most countries that I know, for example, a Government can only exist within a single legislative session (though there can be more than one within that, and specific posts can, in turn, change within those — though in the UK there's more of a distinction between simply replacing a person or two, and a full-blown reshuffling — see for example https://en.wikipedia.org/wiki/Cameron_ministry which lists three different Cabinets, but with internal changes within those. e.g. Philip Hammond replacing Liam Fox as Defence Secretary in the first Cabinet); but from what I can tell, in the US the Cabinet continues as a single entity throughout a multi-term presidency, which in turn doesn't map cleanly to legislative periods at all.

[jpmckinney]

Yes, it would be a new hierarchy of organizations and posts. The legislative periods should be shared between the executive and legislative branches where possible (like in Westminster systems where Cabinet members are also MPs). I don't have additional knowledge of other systems' executive branch than what you described. In the US, the House of Representatives serve two-year terms, the president four-year terms, and the Senate staggered six-year terms. So, I think each would have its own set of legislative periods.

[kaerumy]

For Malaysia (based on UK system), we use posts with start-end dates for this, and then we simply filter by date range of particular session we want results for.

Organization: Cabinet with Minister Posts Organization: House of Representatives with Member of Parliament Posts

We would only use one Cabinet org and add posts with start and end dates for each position. The same for House of Representatives.

Post start/end date queries are good enough for us to get persons of specific legislative session(s) without additional complexity of this relation property.

Even if Federal Ministerial session is different from State Assembly session, doing this, we could still get results for example of who were Federal Ministers (Cabinet) during a different State Assembly session which has different but overlapping start/end dates, just from start/end property of posts in Cabinet.

[jpmckinney]

Thanks @kaerumy. With this model, how do you find a minister's successor?

[tmtmtmtm]

@kaerumy, if a Post can only ever have one Member, I'm curious as to what benefit you're getting from even using Posts in the first place, rather than just making these plain Memberships?

I'm also wondering what the rest of your logic looks like. Is the Cabinet a completely fluid thing, with people being appointed or dropping out at any time? Or are there individual Cabinets that can be referenced, with a large number of members starting and finishing at the same time?

Since I gave the UK example above, there has been a new election, so the position is even clearer. The new election brought a new government — even though it's with the same Prime Minister — the Second Cameron Ministry.

During the the first Cameron government, there were three distinct Cabinets — as you can see on the Wikipedia page for it — although individual members can be replaced within each (e.g. Defence in the first Cabinet).

To be able to produce a page similar to that from Popolo data, I need to store somewhere the various dates of each change of government, and of each cabinet. In your model, where are those stored? Or is this not really a concept you have at all?

Once I have an Event for each of these, it seems better to be able to directly reference those within each Membership: primarily for purposes of good data hygiene (if it turns out that I made an error in the date I thought the Cabinet formed, I want to only have to correct it in one place, not in each individual denormalised Membership of it, both for speed and simplicity, and to avoid the additional risk of inconsistent data if I miss one, or my application dies mid-update etc.), and to have my data more accurately reflect its intent, and enable me to directly ask questions in both directions: "Show me the members of the Second Cameron Cabinet", and "Show me all the Northern Ireland Ministers" — where, importantly, I want to not only get a single start-date and end-date for each, but to see in the results, for example, that Peter Brooke's time in this position spanned both the Margaret Thatcher and John Major governments.

I'm also concerned with reusability here. Where different groups use a consistent approach, then we can create generic tools that will work across multiple datasets; but if every country has its own different modelling approach, those become largely impossible.

[kaerumy]

@jpmckinney to get successor for Posts, at this time we would query for Member for that post whose start date is greater than Member we're interested in. If more than one, than just first result sorted by start date.

eg. from the results of this: http://sinar-malaysia.popit.mysociety.org/api/v0.1/search/posts?q=%22*p104*%22

@tmtmtmtm we have more than one Member per Post, we have House of Representatives with Memberships to MP Posts:

https://sinar-malaysia.popit.mysociety.org/posts/53633fbb19ee29270d8a9ee1

I agree that in such cases, having a related Event attached to a Post Membership (or just Membership) would be useful. We would use it in similar way to UK. First, Second Cabinets of Foo PM, Parliamentary Sessions, Legislative Terms etc.

For Cabinet, we would probably model it in similar way to House of Representatives in Malaysia, have a Ministerial Cabinet (Organization) and then attach Events to them.

+1 also to standardise on models where possible to reduce development especially with similar parliamentary system like Westminister (lots of Commonwealth countries). We had to write two versions of our own UI to Popit to handle Posts, a short term hack and longer term more complete AngularJS replacement. It would be a waste if someone couldn't reuse our efforts.

[wfdd]

Was this ever resolved? My first thought was to create an Organization for a legislative period to use in concert with organization_id in Memberships. I was about to open a new issue with

When there's no intermediary Post between an Organization with a founding and dissolution date and a Membership without a start and end date, should we assume that the Membership lasts for the entirety of the Organization's existence? I'm imagining the Organization being a legislative period and the Membership that of a legislator.

when I thought to search. I see everypolitician is now using Events and a 'legislative_period_id', which I don't think is in the standard.

My motivation is to bring openpatata/openpatata-data closer to the standard and I would rather avoid Posts.

[jpmckinney]

This hasn't been resolved, but I believe the most likely resolution is to add a legislative_period_id on Membership that points to an Event, which is the legislative period like "113th Congress".

At any rate, you should not use an organization for a legislative period.

Also, the semantics of a legislative period would be such that the membership is assumed to have ended whenever the period ended.

[wfdd]

That would be a correct assumption, would it not? The legislative period is the period between elections.

[jpmckinney]

Yes.

[wfdd]

Right, the last paragraph looked like it referred to Organizations before your edit.