Vote class and properties about popolo-spec

[jamesturk]

do you have notes from the follow-up session we did after lunch on the first day?

[jpmckinney]

They will soon be available as new draft specs.

[jpmckinney]

To do:

• Add JSON-LD context, Turtle example, JSON-Schema for new classes

[jpmckinney]

First public working drafts of the specs are now available (not linked from main pages):

• http://popoloproject.com/specs/motion.html
• http://popoloproject.com/specs/vote-event.html
• http://popoloproject.com/specs/count.html
• http://popoloproject.com/specs/vote.html

A major difference from the PoplusCon discussions is the addition of a VoteEvent class. At PoplusCon it was unclear whether a Motion and a VoteEvent were the same thing; since a Motion may be voted on multiple times (e.g. with different methods), they must be separate classes.

We discussed adding a property for "the person who requested a recorded vote." However, different legislatures have different rules for recorded votes; for example, in some legislatures, the request is itself a motion which may fail. You can find interesting details on Wikipedia. Given that this property was of less interest, I will postpone its inclusion until more people voice support.

We had used the words “tally” and “ballot” instead of “count” and “vote”, but on further research, these proved to have undesired meanings. I think we will have to live with the ambiguity of the word “vote”.

Terms rejected: A "division" has a different meaning in the US, where a division allows for accurate vote counts without recording names (e.g. people literally stand and divide into groups to be counted). A "ballot" usually refers to a paper form with specific options, typically used for secret votes, not recorded votes. "Roll call" is ambiguous, as it can simply refer to the calling of the names of people from a list to determine presence and absence. A "tally" is a running or unofficial score; it doesn't represent a final or official score.

[akuckartz]

I have briefly looked at those drafts. OParl intends to add such data in the future. We have something a bit overlapping with Motion which is currently named oparl:Paper and oparl:Consultation. A concise version in English will be made available in a few weeks.

So far some details have turned out to be more difficult in practice than we thought it would be. Example: the number of votes for the different options is not necessarily documented. Often it is only documented which parties supported the successful option but no numbers are provided.

[jamesturk]

I'm not entirely sure I yet understand the distinction between Motion and VoteEvent, you mention there being multiple votes for a motion, but it looks like Motion:VoteEvent is 1-1 relationship in the example?

(oh, and +1 on the changed names being more preferable from our perspective)

[jpmckinney]

@jamesturk Oops, fixed the example JSON.

[jpmckinney]

@akuckartz

Often it is only documented which parties supported the successful option but no numbers are provided.

This is a good use case to keep in mind. Can you link to an example?

I found:

https://github.com/OParl/specs/blob/master/dokument/master/chapter_8100.md
https://github.com/OParl/specs/blob/master/dokument/master/chapter_8120.md

[akuckartz]

@jpmckinney A complete example set of OParl data will also be provided within the next few weeks.

[jpmckinney]

Closing issue. Report feedback in new issues.