Template talk:Infobox election

From Wikidata
Jump to navigation Jump to search

Point in time vs start/end times

[edit]

This seems to suggest that point in time (P585) should only have multiple values in the case of a multi-round election, and where any other type of election spans a longer period, start time (P580) and end time (P582) should be used instead. This doesn't match current practice, however. Single round elections can take place over a two or three day period (this is increasingly true the further back in time you go), and often point in time (P585) is used to list those: see, for example, 1939 Hungarian parliamentary election (Q16985284), or 2002 Czech legislative election (Q24176), or Namibian parliamentary election, 2009 (Q995871). I think this should be an acceptable use, and where an election happens on two days that are non-consecutive, this would actually be more accurate than using start/end times. (As a slightly separate case, there are also cases where different voters vote on different days, for example historically in New Zealand — 1935 New Zealand general election (Q7016128) etc.) --Oravrattas (talk) 06:09, 26 August 2020 (UTC)[reply]

@Oravrattas: First, I apologize. I did not take care of my whatchlist until your ping. The date it's not much important for the infobox calculations, left to determine whether "today" the elections are done or to do, but for this information I take the first one. Beside that, it is only used to display. However, I agree that the description of options in the ontology model should describes with no limitations (more or less as your descriptions). Amadalvarez (talk) 14:27, 30 August 2020 (UTC)[reply]

Duration of election campaign

[edit]

This suggests that duration (P2047) be used with applies to part (P518): election campaign (Q11642595) to note the length of an election campaign. I have never seen this usage before, and a quick check shows it only currently being used on a handful of Catalan elections. This doesn't feel like the right way to model this to me: can you give a little more explanation on what this is saying and how it would apply across different jurisdictions and types of campaigns? --Oravrattas (talk) 06:15, 26 August 2020 (UTC)[reply]

@Oravrattas: You're right. I did not find any reference to campaign duration. So, without a specific property and without the idea that its creation was necessary, I used the generic duration (P2047) + qualifier. Which else do you suggest ?. The number of cases created are few and easy to change. Amadalvarez (talk) 14:37, 30 August 2020 (UTC)[reply]
@Amadalvarez: I don't really know what to suggest, because I don't really understand what you're trying to convey with it, or how that would work internationally across lots of different legal domains, elections types, etc. If this is mainly about noting a legal restriction on when campaigning can happen, I suspect that's something that might be better expressed on the class, than the individual elections. --Oravrattas (talk) 04:49, 2 September 2020 (UTC)[reply]
@Oravrattas: Yes, it is, and certainly can be move to the class. But, if you considered it is too much complex to handle correctly because are several formules, not just a x days before election day, we can ignore it. If we keep it, do you agre with P2047+518 or something else?. Thanks. Amadalvarez (talk) 06:57, 2 September 2020 (UTC)[reply]
PS: In a couple of days I'll upload a new version with some of the changes you suggested.
@Amadalvarez: In terms of the preferred model I think I'd lean more towards adding it specifically to a campaign related item (i.e. an instance or subclass of election campaign (Q11642595), like campaign for the 2020 United States presidential election (Q64827016), electoral campaign in Japan (Q2539756) etc.) It's not something I've given a lot of thought to, or even know that much about in an international setting, to really know what the various rules are likely to be, but it seems like something that will have a lot more flexibility on a separate campaign item/class rather than on the election itself. In terms of connecting the campaign and the election, we don't have a lot of examples yet, but facet of (P1269) seems most common so far, and seems like a plausible approach. --Oravrattas (talk) 18:35, 2 September 2020 (UTC)[reply]
@Oravrattas: If I understood, you're talking about campaign information (item) and how to link it to the election item. But I'm just talking about the duration (in days) of the campaign (it is, a numeric class, no a item class), in order to calculate the icon that will be displayed next to the date. Therefore, it is not an important function and can be removed if it should be a problem. Still, we should have a solution, in case anyone claims it. Amadalvarez (talk) 19:38, 2 September 2020 (UTC)[reply]
@Amadalvarez: Sorry for the confusion. There are two parts to this: the first, and more important, is where to store this information. My inclination is that if we want to store this information at all, it should ideally live on an item specifically about a campaign (or a class of campaigns) rather than an item about an election. More generally, I think this is one where we should probably hold off on really deciding very much until we see what people tend to actually do or need, and let it arise a bit more organically, rather than formalising very much at this point. (My second part was more of an incidental aside about how a campaign item gets tied to an election item, and can largely be ignored for now. It was mainly a note about what's starting to happen already with the campaign items that already exist.) --Oravrattas (talk) 20:18, 2 September 2020 (UTC)[reply]
@Oravrattas: OK. In your pre-last messages talked about "might be better expressed on the class", and I agree thinking in "class for election", for instance presidential election in France (Q890055), instead in every session of these elections. However, use the campaign item doesn't allow acces to this data for those elections without campaign info item. Amadalvarez (talk) 05:08, 3 September 2020 (UTC)[reply]

Following / Followed-by on voting rounds

[edit]

I'm assuming that the gray box suggests that certain properties should explicitly not be used (as in other cases you mark things as 'optional'). Voting rounds are marked as not using follows (P155) and followed by (P156), but it seems reasonable to tie the rounds together in-place like this (e.g. on first round of Slovenian presidential election, 2017 (Q43189475) and second round of Slovenian presidential election, 2017 (Q43189392)) as otherwise navigating between them would only be via the 'parent' item. --Oravrattas (talk) 06:20, 26 August 2020 (UTC)[reply]

@Oravrattas: Good observation. Gray originally meant that should not be used. Afterward, I found that some may have content, although Infobox doesn't used it, and I added some explanation.
P155 & P156 should point to the prev/post session of the same kind of election in order to be able to travel through time and make comparative with the equivalent previous. The case of two rounds breaks this rule, because is so false say that 2nd. round is next of the first round, as say that this is the next of the previous 2nd. round. That's the reason I left the box in gray, because your proposal is correct to solve the relationship inside one singular election, but useless to use to do comparative calculations and to travel, because the first as no P155 and 2nd. has no P156. Seeing this, the Infobox ignores this case and get previous item via the parent item. So, we may decide which one is the best solution to take without the pressure of what infobox does. By the way, when a double round election is solved at first round, like 2020 Belarusian presidential election (Q75556449), the structure disappears and the parent item become the first and only item. Salut !Amadalvarez (talk) 15:30, 30 August 2020 (UTC)[reply]
I suspect the main issue here is what the "equivalent previous" is, and I'm far from convinced that most people would expect that a second round of voting in, say, a Presidential election should "follow" the second round of voting in the previous Presidential election, rather than the first round of voting in this one. In purely practical terms, I think we do need a way to easily get from the second round item to the first round item, without having to go via the parent: what would you suggest for that? --Oravrattas (talk) 04:52, 2 September 2020 (UTC)[reply]
@Oravrattas:. As I say, it's not a problem to Infobox, because it travel back through the parent and ignore P155 & P156 of round items. We must well describe the case, because first doesn't have P155 & second doesn't have P156, a situation that usually correspond to the first and last session of a serie. I'll try to improve in next version of doc . Amadalvarez (talk) 17:36, 2 September 2020 (UTC)[reply]

Office contested on groups of elections

[edit]

This recommends that where an item represents more than one election, a multi-value office contested (P541) should be used.

I think we need to be careful here to distinguish an item with multiple has part(s) (P527) for the separate elections (and should usually have a instance of (P31): group of elections (Q76853179), though in practice this is not always true) — e.g. 2019 Indonesian general election (Q57445374) which consists of 2019 Indonesian presidential election (Q28752050) and 2019 Indonesian legislative election (Q56393441). In most cases this should be the preferred modelling rather than conflating separate elections in a single item, and in such cases the 'parent' item must not include a has part(s) (P527) at all (as we don't want them to be returned for queries of all Indonesian presidential elections, etc). --Oravrattas (talk) 06:33, 26 August 2020 (UTC)[reply]

@Oravrattas: ✓ Done. With P31 = group of elections (Q76853179) mandatory in the parent item.

Eligible voters in voting rounds

[edit]

eligible voters (P1867) is listed as not applying to voting rounds, but should be set on the 'parent' item instead. However, it is not uncommon for each voting round to have a different number: 

SELECT DISTINCT ?item1 ?item1Label ?voters1 ?parent ?parentLabel ?item2 ?item2Label ?voters2
WHERE {
  ?item1 wdt:P31 wd:Q24097670 ; wdt:P361 ?parent ; wdt:P1867 ?voters1 .
  ?item2 wdt:P31 wd:Q24097670 ; wdt:P361 ?parent ; wdt:P1867 ?voters2 .
  FILTER (?voters1 > ?voters2)
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

--Oravrattas (talk) 06:39, 26 August 2020 (UTC)[reply]

@Oravrattas: Well, it's not a problem to change it. But, are you sure some sparql examples are not the result of an error? Having one or two difference voters seems more like a typing or font version error. Amadalvarez (talk) 15:42, 30 August 2020 (UTC)[reply]
After seeing the info from french elections, seems that they do not have a "list of electors" but a "electors registered", so, probably the figures may change, if we assume that people must register by each election. Amadalvarez (talk) 18:26, 30 August 2020 (UTC)[reply]
During the gap between two voting rounds people die, or become old enough to vote, etc. How this plays out in practice in terms of who can vote, and what numbers are published, are likely to differ in practice, but there are also sometimes quite lengthy periods between voting rounds, in which case different numbers seem increasingly likely. From a modelling point of view I think we need to assume that the numbers can be different, and so the default approach should be to record this on each round. In practice, consumers of the data can certainly choose to assume that if it's on the parent, but not the individual rounds, then it applies equally to each, and we may wish to document that that's acceptable, but I don't think that should be the default. --Oravrattas (talk) 05:01, 2 September 2020 (UTC)[reply]
@Oravrattas: ✓ Done. It's differenciate in next version. --Amadalvarez (talk) 17:28, 2 September 2020 (UTC)[reply]

person-oriented or party-oriented candidates

[edit]

It is noted that the instance of (P31) of candidates will be checked "to determine if the election is person-oriented or party-oriented". This is probably a useful heuristic in many circumstances, but I fear it can give misleading results in others, as those concepts aren't necessarily very well defined. 2019 United Kingdom general election (Q30173038) for example only has parties listed as candidates, but, like all UK general elections, would usually be classed as person-oriented rather than party-oriented. This is largely a practical matter: there were over 3000 candidates in that election, and to list them all on the page for the election itself would be impractical, so they are listed via candidacy in election (P3602) statements on the candidates themselves, instead. A UK by-election, which works in essentially the same way, would tend to have the individual candidates listed on the election item rather than the parties. --Oravrattas (talk) 06:47, 26 August 2020 (UTC) @Amadalvarez: — making sure you've seen these --Oravrattas (talk) 10:41, 30 August 2020 (UTC)[reply]

@Oravrattas: I’m not an expert, but it seems to me that “party-oriented” elections are only the proportional type. The work presented and the operation of the infobox is oriented towards aggregate final results, but does not go into how they have been obtained. It is true that open or closed lists work differently and those elected by constituency, as in Britain they are as people, but add to the result in party seats. The information and structure of the lower levels with the detail of results, for example by constituency, has yet to be worked out, at least on my part. Amadalvarez (talk) 16:54, 30 August 2020 (UTC)[reply]
Yes: I think in lots of such cases, we would ideally have an individual item for each separate constituency election, and I think we're already starting to see that happen more frequently, even in cases where the Wikipedias don't separate these out. The elections to the EU Parliament are a good example of this: somewhere like the UK which has multi-member constituencies there, has individual items for 2019 European Parliament election in South West England (Q63852521) etc back to the 2009 election, but only a combined 2004 European Parliament election in the United Kingdom (Q2704885) for the earlier ones, as far as I can see. There's also a parallel here with how the US Presidential election works, where it's really a separate election in each state. These raise quite a few modelling questions, and I think we need to document the various permutations well, as different types of queries will generally want different results (e.g. if you're generating a list of all national presidential elections in 2020, you probably only want a single entry for the US, rather than 50. --Oravrattas (talk) 05:20, 2 September 2020 (UTC)[reply]

bad structures

[edit]

Open list with a structure to analize and incorporate, or to fix it, because is incorrect. Amadalvarez (talk) 04:57, 3 September 2020 (UTC)[reply]

Please, leave your opinion about what to do, and check it when ✓ Done:

European Parliament election

[edit]

Any suggestion about items for European Parliament (EP) election ?.

  • Q28226351#P991 with list of elected persons (accounted in P1114), without any ties to the party, neither the country nor the EU.
  • So, there is no formula to determine reallocation from country party to parlamentary groups.

Thanks for your suggestions. Amadalvarez (talk) 20:39, 4 September 2020 (UTC)[reply]

After version 1.0

[edit]

Hi, @Oravrattas: I give you a long answer about the structure according to content level, to discuss it. I invite cawiki colleagues @KRLS, Davidpar, KajenCAT, Townie: who have been involved in previous debates and works about elections. I trust that we can also count on their knowledge.

Last Sunday, I uploaded a new version which incorporates a lot of the changes we had discussed in previous sections. I have created a set of example pages that I will expand on. I have also updated the documentation with the changes and a new type of voting system that I have partially incorporated: block voting, that apply in "spanish senate".

In addition to the fact that the topic of the long lists of candidates commented in the section "person-oriented_or_party-oriented_candidates ", I want to share some conclusions I have drawn from the work done so far:

  • The initial object of the infobox was to represent "aggregate final information". This concept is what we basically find in WP articles; it is unusual to find articles on results at the constituency level, or on primaries, and so on.
  • Starting with the version that works on the item with summary information, I tried to apply it to lower level items (e.g., constituency) to see what changes I needed to make or how adjust the ontology in these cases. Keeping in mind that it should not be at the service of the infobox, but of its use via query.
  • The concept of "double election" is an improvement born from the design made for two-rounds cases, such as 2017 French presidential election (Q7020999). The idea was to avoid having two infotables (or not showing half the information) in articles like 2008 Spanish general election (Q1419871) where the results of the two chambers are always handled together. However, I find it difficult to apply this solution to any combination and requires reflection or redesign.

So, in addition to the specific aspects improved so far, I have a proposal for discussion that I describe below:

  • I propose that we have 3 levels that I have named: Constituency level, Edition result level, simultaneous level.
    • Constituency level, is the lowest level that has seats to assign to a party or person. At this level we would place the items of each round in the case of "two_rounds"..
    • Edition result level, is the one that collects the final aggregated result of one election's edition. For example, in a state legislative election, it gathers the composition of the chamber, made as the sum of the constituency levels. In some cases, such as municipal elections, this level is a statistical grouping (number of representatives per party, etc.), as the electoral objective (mayor and councilors) is obtained at the constituency level.
    • Simultaneous level, it is, those gathered via group of elections (Q76853179) that correspond to the "double elections" in the infobox. It is a way of presenting the information, but it does not reflect a legally necessary situation.

Examples:

Case constituency result simultaneous
mayor municipality number o city hall by party mayor and councilors
councilors municipalities total councilors / party mayor with councilors
state legislative deputy province / region (as appropriate) state lower + upper chamber
MEP European state Europe N/A
state president state (could also be region) state president + legislative
  • The following table details the structure and characteristics that the items of the 3 levels could have.
  • As a general reflection to frame the proposal, I question the usefulness of the candidate (P726) for operational purposes. Another thing is that you want to have a documentary content of all the candidates, even those who have lost and some will have no other reason to appear in WD.
  • nevertheless, in the case of single winner elections (presidential, etc.) it may be interesting to have the finalist candidates, who will probably be in future elections and thus will be able to show their evolution.
  • For reasons of homogenization of the format of the items of detailed results, and thus facilitate their exploitation, we propose that the constituency level has the same ontology, regardless of the voting system.
  • Regarding participant (P710), I don't really know which should be its role. For instance, in 2017 German federal election (Q15062956), seems to be used as a P726. Any suggestion will be welcome.
Level property party-list personal list
Constituency:
  • level where seat is provide, won by a person or assigned to a party.
  • One item by constituency & edition

If this level doesn't exist:

  • do not have the personal names
  • can not analize/draw results by territory

May exists a lower level of this?

  • yes, for statistical objectives. For instance, vote distribution by regions in EU elections where constituency level is country.
  • it should collect votes by party, but not elected seats nor people.
 instance of (P31) = some specific values to identify the level, as happen with group of elections (Q76853179) or voting round (Q24097670)
subclass of (P279) = kind of election/institution.

>Ex.:election to the senate of Spain (Q56821289)

applies to jurisdiction (P1001) = constituency for a territory and kind of election/institution.

>Ex.:Girona (Q58214114)

follows (P155) & followed by (P156) = previous and next edition for the same election
point in time (P585) = specific for this constituency to prevent was different for the official election day
office contested (P541), may be get from P279 item

+ number of seats (P1342), may be get from P1001 item

part of (P361) = edition results item

>Ex.:November 2019 Spanish Senate election (Q67795085)

candidate (P726)

May be filled before election.

In direct elections and other cases, candidates may be considered to be informed in order to use them before the election.

In elections with party lists, it can be excessive to enter personal information of all candidates from all parties, many of which would involve creating new person items with reduce content and dubious future.

successful candidate (P991)

Fill it after election in any case.

Info of people may be used to spread it, for instance, create P39

with elected people info:

person item + votes received (P1111) + member of political party (P102) /represents (P1268) + running mate (P6149), if applicable.

with # of positions won:

party item + votes received (P1111) + number of seats in assembly (P1410)

eligible voters (P1867), ballots cast (P1868), total valid votes (P1697), number of spoilt votes (P5044), number of blank votes (P5045), etc., of constituency
voting system (P8196), may be get from kind of election/institution (in P279)
Edition results:
  • Aggregated results for the whole edition of one election
  • it usually fits with the level of WP articles about elections.
  • This level does not exists when the Constituency level is the top, for instance, in presidentials or election of mayor by council of municipality (indirect), etc.
 instance of (P31) = kind of election/institution.

>Ex.:election to the senate of Spain (Q56821289)

applies to jurisdiction (P1001) = territory of the election.

>Ex.:Spain (Q29)

follows (P155) & followed by (P156) = previous and next edition for the same election
point in time (P585) = official election day
office contested (P541), NOT explicit. It must be get from P31 item

+ number of seats (P1342), NOT explicit. It must be get from P1001 item

part of (P361) = simultaneous level item

>Ex.:November 2019 Spanish general election (Q65121437)

candidate (P726)

May be filled before election.

In direct elections and other cases, candidates may be considered to be informed in order to use them before the election.

In elections with party lists, it can be excessive to enter personal information of all candidates from all parties, many of which would involve creating new person items with reduce content and dubious future.

successful candidate (P991)

Fill it after election in any case.

Info of people may be used to spread it, for instance, create P39

with elected people info:

person item + votes received (P1111) + member of political party (P102) /represents (P1268) + running mate (P6149), if applicable.

with # of positions won:

party item + votes received (P1111) + number of seats in assembly (P1410)

eligible voters (P1867), ballots cast (P1868), total valid votes (P1697), number of spoilt votes (P5044), number of blank votes (P5045), etc., of constituency
voting system (P8196), may be get from kind of election/institution (in P279)
Simultaneous level:
  • It's an special item to link to two edition election item.
  • Linked elections are not only "coincident date election", but must be related to each other. For instance, two-chamber elections in bicameral systems, or also, municipal elections that elect mayor and councilors separately, in two direct voting.

Which type of elections can be shown together by the infobox?:

  • When the two elections are party oriented, the format is the already implement, that combine both results party by party
  • With a unipersonal election (mayor, for instance)+ a multipersonal election (counciliors)
 instance of (P31) = group of elections (Q76853179)
follows (P155) & followed by (P156) = previous and next edition for the same election
point in time (P585) = same date as its linked elections
office contested (P541) + number of seats (P1342), may be get from each election item
has part(s) (P527) = the linked elections item
candidate (P726)

NOT USED in this level

successful candidate (P991)

NOT USED in this level

eligible voters (P1867), ballots cast (P1868), total valid votes (P1697), number of spoilt votes (P5044), number of blank votes (P5045), etc.,

NOT USED in this level

voting system (P8196),

NOT USED in this level

All of ping receivers, take your time and make yours suggestions, please.

Salut ! Amadalvarez (talk) 21:28, 8 September 2020 (UTC)[reply]

@Amadalvarez: Thanks for taking the time to put all this together, but I'm finding it a little difficult to follow some of it as it's quite abstract and there are so many permutations to consider. Can we build up a set of exemplar reference cases of what we believe are as close to perfectly filled-in items as possible for each permutation? (If we need to add more data to some of those items to make them better first, I'm happy to help out with that) --Oravrattas (talk) 09:46, 9 September 2020 (UTC)[reply]
@Oravrattas: Yes, it's my idea and, if it's possible, show its results in infobox too. Until now, you can see in Template:Infotaula eleccions/series examples1 one complete serie of constituency level with 4 senators + edition results level with full senate + simultaneous level with senate & congress. Thanks, Amadalvarez (talk) 10:43, 9 September 2020 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Template_talk:Infobox_election&oldid=1305533951"