Wikidata:Property proposal/number of negative votes
number of negative votes edit
Originally proposed at Wikidata:Property proposal/Organization
| Description | Number of votes that a referendum, proposal, bill, etc. has been rejected in a vote. This property is related to "number of support votes" (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 | no, as a part of yes and no |
| Data type | Number (not available yet) |
| Domain | elections. Could be use as a principal property or as a qualifier |
| Allowed values | Natural number |
| Allowed units | N/A |
| Example 1 | Czech European Union membership referendum (Q3501000) → 1.010.448 |
| Example 2 | Slovak European Union membership referendum (Q3491184) → 135.031 |
| Example 3 | Catalonian constitutional referendum (Q3782632) → 533.742 |
| 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 support votes") has led to the implementation of solutions such as votes received (P1111) + 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:55, 11 September 2020 (UTC)
Discussion edit
Support, as a proponent. Amadalvarez (talk) 21:15, 12 September 2020 (UTC)- Support--Pere prlpz (talk) 16:26, 15 September 2020 (UTC)
- Support--FranSisPac (talk) 22:52, 15 September 2020 (UTC)
- Support--ESM (talk) 15:13, 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:28, 21 September 2020 (UTC)
- Next text duplicated in Wikidata:Property proposal/number of support votes. Keep here for documentation reasons.
- 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)
- Support I'm agree with Amadalvarez --Davidpar (talk) 13:55, 3 October 2020 (UTC)
