Add start_event and end_event to Membership

[jpmckinney]

Add start_event and end_event properties to Membership, to satisfy the TheyWorkForYou use case described in #20.

[akuckartz]

+1

[kaerumy]

We have an interesting use case here in Malaysia, for possible need to also have "status" of membership eg. current, suspended, expired.

Should we consider a status field, or is it better to use this start/end field?

In this case we have an MP who has been suspended for 6 years from his party. News report considers that this person is no longer considered a representative of his party in Parliament.

http://www.therakyatpost.com/news/2015/04/22/one-less-parliament-seat-for-bn-due-to-suspension

[guglielmo]

+1

[akuckartz]

Regarding the use case by @kaerumy. I think that it is important that no information is overwritten and lost. Example: If a membership was suspended for some time and the status then changes to current then the information about the former suspended period should still be available.

[jpmckinney]

It depends on the use case. If you want to track all suspensions, then you should instead create an Event (or a subclass of the Event class that adds a property to refer to the specific person) with a start and end date for that suspension, instead of trying to fit an entire Suspension model into the Membership model.

For the simple use case of determining "is this membership active or not?" then a status property is probably enough.

[jpmckinney]

I've created a new issue #98 for the status property. Please continue the discussion of this property there.

[tmtmtmtm]

Can you give an example of what this would look like in the common case of an MP resigning and being replaced several days later by someone else (as a straight party substitution, not a new election)?

[jpmckinney]

Like this? https://gist.github.com/jpmckinney/6e7d905c518d24a0b6ab

[breyten]

This might be taking things too far ;), but it also seems to open up the possibility to have a list of events associated with a membership, then use the event's classification property to denote what happened (Ie. end or start). That would be less deterministic, however.

[tmtmtmtm]

@jpmckinney : how can I tell from that (other than by parsing a plain text field) that the two are connected — i.e. that Jane Doe is actually replacing John Doe?

[jpmckinney]

That's a different use case. You'd probably want to instead query by Post and look at the succession to satisfy that use case.

[jpmckinney]

Also, if that's too complicated, we can add properties for following/preceding membership. Event already has followingEvent and precedingEvent, so we can do something similar for Membership.

[tmtmtmtm]

You'd probably want to instead query by Post

That presumes Posts, which as per multiple previous discussions, often don't make much sense in the context of modelling a Parliament: particularly where there aren't single-member constituencies, as will most often be the case in this scenario. (In single-member constituencies, it's more common that a departure triggers an election, rather than a straight replacement).

[tmtmtmtm]

use the event's classification property to denote what happened (Ie. end or start).

Even in really simple cases, I strongly believe it's essential that Events have well-structured classifications, and that these should largely be the same everywhere. Otherwise we're just multiplying the number of places where out-of-band information is needed to understand the data model, making it impossible to build common tooling.

We've (hopefully) already learned that lesson from things like not having a structured way to mark an organization as a Political Group/Party/Faction etc, thus making it impossible to unravel parallel memberships in a consistent manner.

[tmtmtmtm]

Event already has followingEvent and precedingEvent

It does? I can't see anything on http://www.popoloproject.com/specs/event.html about that…

[jpmckinney]

Oops, it's not in the spec, but it is in bio, from the inventory of terms. Anyway, would a property to denote the following/preceding membership satisfy the use case of marking that Jane Doe succeeds John Doe?

[akuckartz]

Are John Doe and Jane Doe different persons ? Or is this about changing properties (such as givenName or gender) of a person ?

[jpmckinney]

Different people.

[jpmckinney]

@rusosnith

[rusosnith]

I think this could algo be useful to add Source information to Start and End of a membership

This is pretty important if we want journalists to trust in our datasets, we have to provide a way of checking the source of the data provided.

[jpmckinney]

ROLL UP

For the use case of learning why a membership started/ended (raised by TWFY) and sourcing that fact (as raised by @rusosnith), and for avoiding denormalization/duplication of information (e.g. a common start date for all members elected on the same day) I think start_event and end_event still makes sense. A codelist for classification should be created to make the date more interoperable. See #111 (comment) about un-dated events.

For the use case of determining which preceded/followed another one without using Post, add follows and precedes – terms used by many specs.