Naming of dates for easy updating when required. about popolo-spec

[jpmckinney]

There are many ways to go here. Right now, no class has an array of dates, so we don't need names to disambiguate between different dates within a single document. To make sure I understand correctly, we want to be able to tag dates on different documents, so that we can find them easily later. The only use case given so far are dates on the parliamentary calendar, e.g. an election date or a term's end date, and this use case only affects end dates on Memberships for members of that parliament. If I understand, an important motivator for these tags is to be able to disambiguate between someone whose membership actually ended in 2012, and one whose membership was merely projected to end in 2012 but hasn't actually.

It's important to mention that in RDF, we can tag dates with user-defined datatypes, and avoid this question altogether.

Playing devil's advocate, what's wrong with the following proposal: Don't store future end dates. Is it really necessary to put on the Membership document the projected end date? Couldn't this information be provided in a less error-prone way, e.g. through a calendar? In this way, you would only set the end date once memberships had in fact ended.

Update: More importantly, you aren't actually storing the Membership's end date by doing what you propose. You're storing the date of some other thing - an end of a term or the date of an election. Popolo has no knowledge of Terms or Elections, but perhaps it should. Those dates should be on those objects, not on Memberships. Consider the cases where someone's membership ends before the projected date, e.g. resignation, death, etc. I'd prefer to add new classes to handle your use case; I anticipate a great deal of confusion if dates becomes objects that can represent all sorts of potential future outcomes.

[jpmckinney]

The more I think of it, the more I think you actually want an Election class (or a more general Event class), but since you don't have that class, you need to put its properties on every object that has something to do with that event.

[jpmckinney]

An Event class seems like the only way to avoid a logical extension of the original proposal in this issue, which can lead to:

# Membership
{
  "person_id": "1",
  "organization_id": "2",
  "end_date": [
    {
      "date": "2018",
      "note": "General election"
    },
    {
      "date": "2016",
      "note": "Court may sentence to incarceration, prompting resignation"
    },
    {
      "date": "2013-03-30",
      "note": "Heart attack"
    }
  ]
}

from popolo-spec.

[jpmckinney]

@evdb see #22 for standards relating to an Event class

[evdb]

I think that using the events (#22) would address the motivations for adding names to dates. Closing.

[jpmckinney]

Issue summary: The recommendation would be to create an Event, which stores the date on which all memberships end (e.g. at prorogation, dissolution, etc.). Logic should be added to that event, such that once its date passes, all open-ended memberships to which it applies end on that date. This avoids a conflict in cases where a membership ends before the projected date.