Wikidata:Property proposal/number of support votes
number of support votes edit
Originally proposed at Wikidata:Property proposal/Organization
| Description | Number of votes that a referendum, proposal, bill, etc. has received support in a vote. This property is related to "number of votes against" (currently proposed) and number of abstentions (P5043). Other vote-counting properties are aimed at general elections where voting translates into support, but there is no explicit option to vote for / against. |
|---|---|
| Represents | yes, as a part of yes and no |
| Data type | Number (not available yet) |
| Domain | elections |
| Allowed values | Natural number |
| Allowed units | N/A |
| Example 1 | Czech European Union membership referendum (Q3501000) → 3.446.758 |
| Example 2 | Slovak European Union membership referendum (Q3491184) → 2.012.870 |
| Example 3 | Catalonian constitutional referendum (Q3782632) → 1.899.897 |
| Planned use | Apply in all referendum items |
| See also | number of abstentions (P5043) |
Motivació edit
The combination of yes / no / abstention is usual in voting in a parliament, in legislative bodies, in referendums, etc. The lack of these properties (this and the proposal of "number of votes against") has led to the implementation of solutions such as P 1111 (P 1111) + qualifier of (P642) = yes / no have been applied (see: Q3491184 # P1111), or candidate (P726) = yes / no + votes received (P1111) as a qualifier (see: Q3501000 # P726). These solutions prevent the results from being treated homogeneously; in addition, they do not allow to add, a qualifier with the positioning of each group in the case of legislative votes. With this property it will be easier to report the results in this type of voting. Amadalvarez (talk) 23:56, 11 September 2020 (UTC)
Discussion edit
Support, as a proponent. Amadalvarez (talk) 21:15, 12 September 2020 (UTC)- Support--Pere prlpz (talk) 16:25, 15 September 2020 (UTC)
- Support--FranSisPac (talk) 22:44, 15 September 2020 (UTC)
- Support--ESM (talk) 15:12, 16 September 2020 (UTC)
- Support--Arnaurs (talk) 15:57, 20 September 2020 (UTC)
Oppose as some referendums have more than 2 options like Puerto Rican status referendum, 2017 (Q30044084) or Guernsey electoral system referendum, 2018 (Q56087909), I suggest to have something more flexible that will work for all cases. Even, when there are only 2 alternatives they can be different from the usual yes/no or for/against, like for 2nd question of the Chilean national plebiscite, 2020 (Q75072406). Dom (talk) 22:26, 21 September 2020 (UTC)
- Thanks, @Dom: The proposal you commented are similar to traditional voting to different candidates, where you always vote "yes" to one (or exceptionally, more than one) of them. Therefore, we must use similar ontology. Even the Guernsey electoral system referendum, 2018 (Q56087909) example is a two-round system (Q615255) case, similar to most presidential elections. We must think how to be able to exchange "traditional candidates" by "predefined options", because candidate (P726) and successful candidate (P991) are "item" type of data. In my opinion, creating items which defines each option beyond a descriptive text, with its date of creation, supporters, etc.
- In the Chilean national plebiscite, 2020 (Q75072406) case you introduce a "two question case", first to know whether yes/no to constitution (basic referendum) and, second, which class of redaction group must be. This case is similar to double elections, for instance, in municipals where choose mayor and councilors, separately, so, must follow a similar ontology: it is, one item by each election (candidate, results, date,..) with a parent item that link both in one only act. Thanks, Amadalvarez (talk) 06:07, 26 September 2020 (UTC)
- @Amadalvarez: So I think that a property for the question is needed as for referendums that have more then one question, then the voting round (Q24097670) when there is more than one as in the example of the Guernsey electoral system referendum, 2018 (Q56087909) that had 4 rounds. Then there must be an other property for the possible answers to the questions which will have a votes received (P1111). Of course the votes received (P1111) must be updated to be applied to referendums.Dom (talk) 17:34, 26 September 2020 (UTC)
- @Dom: Well, we can think in a specific property for questions. Initially, I discarded this option to avoid overloading the number of properties and because the text properties are not too much useful for multilingual, but is not a problem to me. In any case, have you seen the structure I created for Guernsey electoral system referendum, 2018 (Q56087909) and the infobox result ?. Thanks, Amadalvarez (talk) 18:22, 26 September 2020 (UTC)
- @Amadalvarez: So I think that a property for the question is needed as for referendums that have more then one question, then the voting round (Q24097670) when there is more than one as in the example of the Guernsey electoral system referendum, 2018 (Q56087909) that had 4 rounds. Then there must be an other property for the possible answers to the questions which will have a votes received (P1111). Of course the votes received (P1111) must be updated to be applied to referendums.Dom (talk) 17:34, 26 September 2020 (UTC)
- Support I'm agree with Amadalvarez --Davidpar (talk) 13:55, 3 October 2020 (UTC)
