Describe how to link people to posts without implying membership in organizations

[jpmckinney]

The original W3C ORG standard didn’t have a post_id on Membership, but it also didn’t have a means of having start/end dates for holding a Post. With mySociety and Sunlight, we decided to add post_id to Membership, which has the side effect of a Person having multiple Memberships if they hold multiple Posts, which isn’t reality, but was considered acceptable.

One way to have a single membership but multiple posts is to make post_id an array, but that complicates the very common case of a Person only holding 0 or 1 Posts per Membership.

Another way is to create a new Appointment class, to hold the dates during which additional posts are held.

Example: Morgan is a member of House for District 1 from 2010 to 2014, and is also appointed Speaker from 2012 to 2013:

{
  "type": "Membership",
  "person_id": "morgan",
  "organization_id": "house",
  "post_id": "district_1",
  "start_date": "2010",
  "end_date": "2014"
}

{
  "type": "Appointment",
  "person_id": "morgan",
  "post_id": "house_speaker",
  "start_date": "2012",
  "end_date": "2013"
}

[jpmckinney]

/cc @fgregg

[fgregg]

I really like this idea, but we need a really clear distinction between a membership and an appointment.

Particularly since many people are members of a body because they are "appointed" by someone else, people might get confused about what we are really talking about here.

It seems like a key thing that we are trying to get at is that there are posts or roles that do not confer membership in a body. Is that right?

If so, could that just be an attribute of a post?

[jpmckinney]

So, an attribute of the Post would indicate whether being appointed to that post confers membership?

I suppose we could then run validations to ensure there is no Membership is associated to that Post.

And alternately, run validations to ensure that no Appointment is used if a Post confers membership;

[fgregg]

My current use cases would be satisfied, if posts had this confers_membership attribute. I wouldn't need the appointment class, because I can easily get a full list of all current posts.

[jpmckinney]

If there's no Appointment class, then you're okay using Memberships to make the link between People and Posts (with some Posts conferring membership and some not)?

[fgregg]

yes. That's my current favorite solution.

…

On Fri, Feb 3, 2017 at 5:52 PM, James McKinney ***@***.***> wrote: If there's no Appointment class, then you're okay using Memberships to make the link between People and Posts (with some Posts conferring membership and some not)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgxbTW8tRzBDyp2nAdV49KJuf21NGS0ks5rY72rgaJpZM4LwSzf> .

-- 773.888.2718

[patcon]

If I'm understanding correction, putting confers_membership on Post and adding validation seems it could be simplified.

Could Membership and Appointment be generalized to another object (like Association), and then have an association_type that's either "appointment" or "membership" (or some other future type)? Then there's not need for validation logic to ensure consistency, and filtering on "membership" allows a clear "get roles for board posts that are memberships" (rather than "get roles for board members").

(I may be missing some underlying requirement, so please feel free to disregard if so!)

[jpmckinney]

In terms of modeling, that's the same as having an Appointment class, except we're using a type property to distinguish between classes instead of using the class name.

[patcon]

I think I'm operating under the assumption that more classes are less desirable as increased complexity, but perhaps not true. Memberships were always a "linkage" sort of class in my mind. As proposed, introduceing the idea of now having n types of linkages makes the spec a little harder to grok imho

[jpmckinney]

Hmm, I'm remembering a pattern from the UK's electoral candidates project. For candidacy (#104 #43), they had people hold memberships that were linked to posts but not to organizations. You could still get the organization in which the post exists through the post, but by leaving the organization blank on the membership, normal system logic wouldn't count that person as a member of that organization.

@fgregg What if Pupa allowed creating memberships without setting the organization?

@patcon Not setting organization would effectively be the same as having a type flag.

[fgregg]

@jpmckinney, for the UK project, I understand the steps that led to having memberships that were not linked to organizations. I think that this was a reasonable technical solution, but it violates my understanding of what a membership means. For me, a membership means that you are part of a body, so not having a body doesn't make sense.

[jpmckinney]

My understanding of your proposed alternative is that a confers_membership flag on a Post negates the semantics of its related Memberships actually being 'memberships', which seems more confusing to me. Sent from mobile

…

On Feb 7, 2017, at 10:49 AM, Forest Gregg ***@***.***> wrote: @jpmckinney, for the UK project, I understand the steps that led to having a memberships that were not linked to organizations. I think that this was a reasonable technical solution, but it violates my understanding of what a membership means. For me, a membership means that you are part of a body, so no having a body doesn't make sense. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[fgregg]

My proposal is that a a post with a confers_membership=False would not have a related Membership

[fgregg]

actually, if it is valid for posts to not have related memberships, then I think we would be good. pupa and other downstream tools would need to handle a confers_membership logic, but the Post class need not.

[jpmckinney]

How do you relate a person to a post if not through a membership?

[fgregg]

ah, I see. Now I think I finally fully understand the distinction you were trying to make between Appointment and Membership

Would be it be accurate that you see an appointment as a relation between a person and a post, and a membership as a relation between a person and a body?

[jpmckinney]

Membership is currently a relation between a Person, Post and Organization. Post is optional. See diagram: http://www.popoloproject.com/specs/membership.html

An Appointment would likely just be between a Person and a Post.

Posts are always related to Organizations. There are no free-floating Posts.

[fgregg]

Reading through this thread again, I think your Appointment class idea is very good.

I think we need a different name than Appointment, though, as it improperly draws attention to the means by which a person comes to hold an office.

some ideas for names, none of which I really love:

• OfficeHolding
• PostHolding
• PostTerm
• Term (I think I like this one the best)

I also think it might have nice to an optional attribute on the Appointment class that can refer to the membership that is a necessary condition for an appointment.

[jpmckinney]

Term sounds good, though (in isolation) it could be confused with the term of the legislature (see #93 where the modelling of legislative periods are discussed)… But if we aren't using Term anywhere else, I think it's fine to use for this purpose, as I can't think of anything better.