search

popolo-project / popolo-spec

International legislative data specifications
http://www.popoloproject.com/
99 stars 18 forks source link

Store reason for start and end of membership #20

Closed evdb closed 11 years ago

evdb commented 11 years ago

This is used in the TWFY codebase to describe the situation in which a representative starts and stops their tenure - see instances in the codebase and a list of example reasons

They should be optional. The keys start_reason and end_reason could be used and the values be plain strings.

jpmckinney commented 11 years ago

This is a provenance question. The PROV-O vocabulary has classes and properties for describing change events in more detail. I'd want to investigate that existing standard before minting new terms. You can help by having a look yourself :)

evdb commented 11 years ago

Perhaps I'm missing something but there does not seem to be anything in the PROV_O spec that is applicable. They would link a start to other classes in the ontology, rather than a simple textual description. The closest thing would be wasStartedBy property (and the related wasEndedBy).

jpmckinney commented 11 years ago

Actually, changeEvent is part of ORG but it's only for changes to organizations. It may however point to how to use PROV for similar events. Anyway, it's important to base standards on existing standards, otherwise it becomes a game of "my standard versus your standard." It's much better for the situation to be "it's your standard versus my standard plus the dozen standards my standard is based on" as is the case with Popolo currently.

jpmckinney commented 11 years ago

Also, PROV-O may not have the single property you want. For the JSON/MongoDB serialization, we can maybe simplify whatever it has to one property. But it's first important to understand how they do things and why they do it that way.

jpmckinney commented 11 years ago

As with #18, I am increasingly of the opinion that the only sane approach is to have an Event class. The Event class should have some type mechanism, whether as a property or by subclassing the event class, to account for all the event types in TWFY.

The membership could reference an Event class with respect to its start and end dates. How does that sound? In this case, we can indeed inspire a lot from how ORG uses PROV-O. We can move the dates out of Membership entirely, but I think many use cases won't have anything on the Event besides the date, and so it's best to leave a mechanism for people who don't need full-fledged events (sort of like how Posts are optional).

It should have occurred to me earlier, but when we talk about making a property like a date into an object, that usually means making that property into a class with its own properties - thus Event. I think this is in line with what you're proposing. It just means more work, because there are about another 10 standards that deal with events that need to be reviewed.

evdb commented 11 years ago

Best implemented with events #22. Closing.