Wikidata:Property proposal/Person
Property proposal: | Generic | Authority control | Person | Organization |
Creative work | Place | Sports | Sister projects | |
Transportation | Natural science | Computing | Lexeme |
See also Edit
- Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
- Wikidata:Properties for deletion – proposals for the deletion of properties
- Wikidata:External identifiers – statements to add when creating properties for external IDs
- Wikidata:Lexicographical data – information and discussion about lexicographic data on Wikidata
This page is for the proposal of new properties.
Before proposing a property
Creating the property
|
![]() |
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2023/09. |
Person Edit
sponsor/introduced by/proposed by Edit
Description | person who presents a bill or resolution to a legislature for consideration |
---|---|
Represents | sponsor (Q7579032) |
Data type | Item |
Domain | human (Q5) |
Example 1 | Health and Social Care Act 2012 (Q5690771) → Andrew Lansley (Q333276) |
Example 2 | Danish Popular Education Act (Q12311795) → Margrethe Vestager (Q270820) |
Example 3 | North Carolina Identity Theft Protection Act of 2005 (Q7054544) → Daniel G. Clodfelter (Q5217216) |
Planned use | in the next month I intend to add this qualifier to all instances of act of the Parliament of Denmark (Q113627831) |
Wikidata project | WikiProject Law (Q8486941) |
Begrundelse Edit
Similar to introduced on (P9448), this property describes who introduced a bill into a legislature, often a member of government. This is different from sponsor (P859) (commercial sponsor of e.g. sport teams), even though both concepts (sponsor (Q152478) and sponsor (Q7579032)) are called “sponsor” in English. C960657 (talk) 22:59, 23 September 2022 (UTC)
Discussion Edit
- seem reasonable BrokenSegue (talk) 01:37, 24 September 2022 (UTC)
- I just realised that we already have moved by (P6939), so perhaps we don't need a specialised property. I have raised the question on Property_talk:P6939#Also_for_acts_of_parliament?. --C960657 (talk) 08:10, 24 September 2022 (UTC)
- Neutral Nepalicoi (talk) 04:07, 3 January 2023 (UTC)
- Oppose; I indeed assume that P6939 would suffice. Maxime Ravel (talk) 05:28, 1 July 2023 (UTC)
has disinherited Edit
Description | someone who received or will receive no or little the subject's property or title even if otherwise eligible, (partially) the opposite of Wikidata:Property proposal/heir or beneficiary |
---|---|
Data type | Item |
Domain | people |
Example 1 | Joan Crawford (Q40475) → Christina Crawford (Q523816) |
Example 2 | Tony Curtis (Q162389) → Jamie Lee Curtis (Q106997) |
Example 3 | Cornelius Vanderbilt II (Q2708289) → Cornelius Vanderbilt III (Q1875953) |
Example 4 | Sir Evelyn Broughton, 12th Baronet (Q75260564) → Isabella Blow (Q1619607) |
GZWDer (talk) 13:34, 10 January 2023 (UTC)
Discussion Edit
- Support Interesting relation, I do think this is useful to have here. ArthurPSmith (talk) 19:52, 10 January 2023 (UTC)
- The property name should be more clear about the direction. "has disinherited" might be a way to go there. ChristianKl ❪✉❫ 18:55, 16 January 2023 (UTC)
- I was thinking more about it. Why isn't it a qualifier? ChristianKl ❪✉❫ 17:57, 26 March 2023 (UTC)
- Oppose This assumes very specific cultural context, specifically the background information that (and what) someone would normally have inherited. It could also be captured with a property such as “bequeathed” taking a list of properties or titles or whatever, and “no value” for this specific case.Karl Oblique (talk) 06:27, 5 August 2023 (UTC)
clan Edit
Represents | clan (Q211503) |
---|---|
Data type | Item |
Domain | human (Q5) |
Example 1 | Kim Dae-jung (Q45785) → Gimhae Kim clan (Q493888) |
Example 2 | Park Chung-hee (Q14356) → Goryeong Park clan (Q12584184) |
Example 3 | Rosamund Kwan (Q714188) → Gūwalgiya (Q5627766) |
See also | family name (P734), country of citizenship (P27), family (P53), member of the deme (P2462), gens (P5025), member of Roman tribe (P11491), Wikidata:Property proposal/Tribe |
Motivation Edit
Clan infomation is useful to represent Bon-gwan (Q846706) or Manchu surname (Q20687684). South Korea previously banned marriage between men and women who have the same surname and sharing the same ancestral home(Bon-gwan (Q846706)). Marriage between men and women who belong to related bon-gwan was taboo. Modern Manchu people have Manchu surname (Q20687684) regardless of their modern Chinese characters (Q8201)-based chinese surnames.
Because there are posibilities that some Koreans in the past without Bon-gwan (Q846706) adopted neighbor's Bon-gwan (Q846706), we can't use family (P53) for Bon-gwan (Q846706). ChoKukSuho (talk) 09:17, 15 January 2023 (UTC)
Discussion Edit
- Request: Please explain why Gimhae Kim clan (Q493888)instance of (P31)family (Q8436) + Kim Dae-jung (Q45785)family (P53)Gimhae Kim clan (Q493888) is wrong. 2A01:CB14:D52:1200:B4D6:18D9:5E63:F68C 21:29, 15 January 2023 (UTC)
- «we can't use family (P53) for Bon-gwan (Q846706).» => Why? 2A01:CB14:D52:1200:B4D6:18D9:5E63:F68C 21:34, 15 January 2023 (UTC)
- Are/were those Manchu and Korean grouping formally recognized/acknowledged by the local State like deme (Q672490): administrative unit in ancient Athens and tribus (Q938560): grouping of Roman citizens were? 2A01:CB14:D52:1200:B4D6:18D9:5E63:F68C 21:34, 15 January 2023 (UTC)
- If this is the case, then it would be a strong argument in favor of a (dedicated) property. 2A01:CB14:D52:1200:141:C262:8BA7:4741 08:15, 21 January 2023 (UTC)
- Because of their population. ChoKukSuho (talk) 08:36, 16 January 2023 (UTC)
- Support I support this proposal on the condition that it will replace member of Roman tribe (P11491) with a more general datatype (but less general than member of (P463)). /ℇsquilo 08:24, 17 January 2023 (UTC)
- Comment Why should it replace it? They are different concepts from different cultures. --Jahl de Vautban (talk) 17:26, 17 January 2023 (UTC)
- Comment I agree with Jahl, clans and tribes are not at all the same thing, Roman tribes had very specific legal implications that most clans do not. Hard no to any replacement.StarTrekker (talk) 04:46, 10 August 2023 (UTC)
- What's the difference to family (P53)? ChristianKl ❪✉❫ 03:59, 29 January 2023 (UTC)
- Comment extremely populous clans are not families. such as Korean Bon-gwans. ChoKukSuho (talk) 15:23, 14 April 2023 (UTC)
- Comment Consider making sure the property won't end up co-opted for Scottish clans? Unless the intention is indeed explicitly to cover that use case? Circeus (talk) 16:42, 17 June 2023 (UTC)
- In any case this property would need a description to be more clear about it's usage. ChristianKl ❪✉❫ 00:00, 18 June 2023 (UTC)
- Support but there are already several properties for clans by specific culture (such as Roman gentes) so maybe there should be a description that makes it clear that more specific properties are avalable.StarTrekker (talk) 04:45, 10 August 2023 (UTC)
place of resident registration at death Edit
Description | the place or administrative unit where the deceased person was registered as having his or her residence at the time of their death |
---|---|
Data type | Item |
Domain | human (Q5) |
Allowed values | instance of, or instance of a subclass of, human settlement (Q486972) or administrative territorial entity (Q56061) |
Example 1 | Gunnar Rönn (Q116273890)place of resident registration at death → Spånga-Kista församling (Q10676706) |
Example 2 | Sven Lindegård (Q5954944)place of resident registration at death → Växjö domkyrkoförsamling (Q10718569) |
Example 3 | Jan Arvid Hellström (Q3828508)place of resident registration at death → Växjö domkyrkoförsamling (Q10718569) |
Example 4 | Hans Rosengren (Q21759275)place of resident registration at death → Karlstad church parish (Q10543924) |
See also | place of death (P20) |
Type constraint – subclass of | human settlement (Q486972) or administrative territorial entity (Q56061) |
Single-value constraint | yes |
Motivation Edit
In many countries, including my country Sweden, the current place of residence of all people living in the country is registered by the government, and this information is kept up to date (it is mandatory to notify the government when you move). An effect of this system is that ”place of death” is recorded as the place where a person was registered when the person died. The officially registered place of death is often misleading, when a person was a registered resident in one district, and died somewhere else, perhaps under circumstances that are important to the biography of the person. This is a problem when information is taken automatically from Wikidata to an infobox (which is often the case on e.g. Swedish-language Wikipedia). For countries such as Sweden, we need the property ”place of resident registration at death”.
The intention is to make it possible to include in Wikidata both ”place of death (P20)” and ”place of resident registration at death (P????)” for persons who have died in countries such as Sweden.
Potentially this could be important to thousands of articles with biographical infoboxes. Jan Arvid Götesson (talk) 00:26, 25 January 2023 (UTC)
Discussion Edit
- Support This is the value that usually is mentioned in sources. – The preceding unsigned comment was added by Esquilo (talk • contribs) at 09:00, January 25, 2023 (UTC).
- is there a difference between place of resident registration instead of just place of residence at death? we already have a property for the latter. BrokenSegue (talk) 22:17, 25 January 2023 (UTC)
- also can you not come up with more than one example? if you can't provide more than one example then I don't think we should make this property. BrokenSegue (talk) 05:10, 26 January 2023 (UTC)
- @BrokenSegue Do we have a property like that? I cannot find it. Could you please do us the favor and link it? Ainali (talk) 08:22, 26 January 2023 (UTC)
- Maybe residence (P551) in combination with the qualifier end cause (P1534). The value death (Q4) and or death of subject (Q99521170) seem to be the most used values for that particular combination, see the following SPARQL question:
- Link to query that gives a frequency table for values for residence (P551)/end cause (P1534).
- Link to query for the full table, although just 287 objects, using the residence (P551)/end cause (P1534) combination.
- However, a person may simultaneously have several residence (P551) but, at least in Sweden, only one "resident registration" for each point in time.
- -- Larske (talk) 16:20, 26 January 2023 (UTC)
- I meant we can use place of residence at time of death as the qualifier. I'm not sure what it means to have a registered place of residence. I don't think that's a thing in the US. BrokenSegue (talk) 18:42, 26 January 2023 (UTC)
- There is an article, Resident registration in English-Language Wikipedia explaining this. The article says: “A resident register is a government database which contains information on the current residence of persons. In countries where registration of residence is compulsory, the current place of residence must be reported to the registration office or the police within a few days after establishing a new residence.” “Neither the federal government of the United States nor any U.S. state has formal resident registration systems.” Roughly speaking, there are two different systems in the world, both centuries old. English-speaking countries have inherited the British tradition of not having resident registration. Before the advent of computers, resident registration was done manually on paper by government officials (in some countries with a state church it was done by clergy on behalf of the government). Jan Arvid Götesson (talk) 20:44, 26 January 2023 (UTC)
- BrokenSegue asked for more examples. I have added examples the differences between “place of death” and “place of resident registration at death” are important in the biographies of those people. The point is however that the majority of people, who live i countries that have the system of resident registration administered by the government, have a “place of resident registration at death” that is not their place of death, so thousands of biographical Wikidata objects would potentially benefit and become more informative and precise.
- Should we not instead add a "place of resident registration" property and then use the valid dates at time of death? BrokenSegue (talk) 22:57, 26 January 2023 (UTC)
- @BrokenSegue It kind of make sense, but I am afraid that it would be less used. First, it would be a tricky Lua call to get it to an info box. Also queriyng will be harder as it would require that it is exactly the same dates on date of death and the qualifier. Ainali (talk) 17:11, 27 January 2023 (UTC)
- BrokenSegue asked for more examples. I have added examples the differences between “place of death” and “place of resident registration at death” are important in the biographies of those people. The point is however that the majority of people, who live i countries that have the system of resident registration administered by the government, have a “place of resident registration at death” that is not their place of death, so thousands of biographical Wikidata objects would potentially benefit and become more informative and precise.
- There is an article, Resident registration in English-Language Wikipedia explaining this. The article says: “A resident register is a government database which contains information on the current residence of persons. In countries where registration of residence is compulsory, the current place of residence must be reported to the registration office or the police within a few days after establishing a new residence.” “Neither the federal government of the United States nor any U.S. state has formal resident registration systems.” Roughly speaking, there are two different systems in the world, both centuries old. English-speaking countries have inherited the British tradition of not having resident registration. Before the advent of computers, resident registration was done manually on paper by government officials (in some countries with a state church it was done by clergy on behalf of the government). Jan Arvid Götesson (talk) 20:44, 26 January 2023 (UTC)
- I meant we can use place of residence at time of death as the qualifier. I'm not sure what it means to have a registered place of residence. I don't think that's a thing in the US. BrokenSegue (talk) 18:42, 26 January 2023 (UTC)
- Maybe residence (P551) in combination with the qualifier end cause (P1534). The value death (Q4) and or death of subject (Q99521170) seem to be the most used values for that particular combination, see the following SPARQL question:
- Comment dont we have this information in the sources as stated in (P248)? --> when we have a death date we can see that it is "stated in" eg. church death record (Q10478639) i.e. that is the book of the "place of resident registration" see e.g. Q7724#P20 the problem is that we dont have all the books as WD objects if we had that we could from the book understand "place of resident registration at death"
- SPARQL every person at a cemetery with a source from a death book church death record (Q10478639) - SPARQL list / map
- OT: I feel we should have Wikidata entries for every Swedish churchbook like August Strindbergs death book Adolf Fredriks kyrkoarkiv, Död- och begravningsböcker, SE/SSA/0001/F I/18 (1906-1916)
- Salgo60 (talk) 15:41, 27 January 2023 (UTC)
- In Swedish I asked the Swedish National Archive what plans they have with linked data - something was promised in 2017 regarding churchbooks and linked data that I dont think they have delivered link. Question: Do we have examples from other countries about Linked data for churchbooks let me know - As the churchbooks are the official registration of a person then that would solve the problem... Salgo60 (talk) 14:30, 31 January 2023 (UTC)
- Support Ainali (talk) 17:17, 27 January 2023 (UTC)
- Oppose I think residence (P551) is enough, with qualifiers end cause (P1534) → death of subject (Q99521170) to indicathe that's the last residence until their death; and nature of statement (P5102) → de jure (Q132555) to indicate that's the value recognized by the legal system, without implying that was actually the real residence of the person. I would not use official (Q29509043) as value here, since it hasn't to be related with goverment records. --Tinker Bell ★ ♥ 09:29, 30 January 2023 (UTC)
- Oppose I agree with Tinker Bell. P551 should do the job. ChristianKl ❪✉❫ 00:03, 31 January 2023 (UTC)
- Oppose Using qualifiers is preferred over new properties. Infrastruktur (talk) 13:26, 31 January 2023 (UTC)
- Note that in, for example, Sweden, official sources related to death does not state where their residence was, but just an administrative area where they were registered. In essence, since it is most common that place of death (P20) on Swedes are the parish where they were registered and should be removed (users have routinely added what the sources say, but on wrong property since no better exist), we would lose data about location and death for them. Ainali (talk) 21:25, 31 January 2023 (UTC)
- @Ainali: Sorry, I didn’t understand. What do you mean when you say we would lose data? Do you mean that we lose data because the actual place of death is often not written into P20 (people instead write “parish where registered at death” in p20), or do you mean it the other way round, that we lose information about “parish where registered at death” when people write actual place of death in p20?
- Another thing: you are right that in Sweden, ”official sources related to death does not state where their residence was, but just an administrative area where they were registered”. If we want to state the exact place of residence at death we would need to state the unique identifier of the property where the deceased had their address at death. However, since the parishes (now called distrikt) are so small in Sweden (typically 15 km by 15 km with a few thousand inhabitants), writing “parish where registered at death” in p20 gives quite an exact piece of information. If it is stated that persons were registered in the parishes of ”Katarina församling, Stockholm” and ”Älghults församling, Kronobergs län” at the time of their death, that information would be acceptable as values for a property called ”place of resident registration at death”, I think. Jan Arvid Götesson (talk) 12:03, 8 February 2023 (UTC)
- @Jan Arvid Götesson My point is that all parishes that are now on P20 really should be deleted as they are just plain wrong. And for these people we probably don't have any source on where they actually died. Hence we will lose data when deleting those. Ainali (talk) 13:09, 8 February 2023 (UTC)
- @Ainali: I understand. All parishes in P20 should be deleted, you say, which means we would end up with no data, because in many cases sources don’t say where a Swedish person died, only their parish of registration at death. That is why I ask for a solution so that both the piece of information ”place of death”, and the piece of information ”place of resident registration at death” can be entered into Wikidata, and automatically retrieved to Wikipedia. Because both those pieces of information are important in a person’s biography. And I think that parish (district) at death is sufficient if we want to state a person’s ”place of resident registration at death”. Parish is not as exact as the street adress or name of the property (”fastighet”), but people who died in the United States only have values such as ”Princeton” (Albert Einstein) in P20. Jan Arvid Götesson (talk) 13:54, 8 February 2023 (UTC)
- @Jan Arvid Götesson My point is that all parishes that are now on P20 really should be deleted as they are just plain wrong. And for these people we probably don't have any source on where they actually died. Hence we will lose data when deleting those. Ainali (talk) 13:09, 8 February 2023 (UTC)
- Comment @Ainali: do you have any examples? Sweden is rather easy to track people compared to United States were you have census. In Sweden we had household books "Swedish household records (Q10527384)" that is a register often updated every year when the priest visited the houses in the church parish. When a person left the church parish or moved inside the church parish the persons record was striked through in the Swedish household records (Q10527384) and a date when he moved and a page number if he moved inside the church parish. If the person moved out (video 10 min) from the church parish he also was registered in a special book "Moving in and moving out records (Q64167115)" and in the parish he moved to they had a book of the persons that has moved in "Moving in and moving out records (Q64167115)" and then he also was registered in the Swedish household records (Q10527384) in the house he lived. When a person died his record was overstrikken in the Swedish household records (Q10527384) for the church parish and a death date was added PLUS he was added in another book church death record (Q10478639) also when persons died we have Estate inventories estate inventory (Q1777837) were they register all the items a persons owned, when he died and where he lived and family members (video Estate inventories)
- An example how controlled it was in Sweden is that we used internal passport (Q3492838) 1555 until 1860...
- - Salgo60 (talk) 00:37, 3 February 2023 (UTC)
Important summary of alternative solutions. I made this proposal. My contribution to Wiki projects is only to write Wikipedia articles, which sometimes include infoboxes that automatically retrieve parameter values from Wikidata. I’m ignorant about Wikidata. I don’t understand the technical things, so I put this in layman’s words. To objective is to be able to have certain information in infoboxes, such as the infoboxes generated with the ”faktamall biografi WD” (English: Infobox person/Wikidata). The information in the infobox should be like this:
Johan Johansson Born 1 May 1920 Skirö parish, Sweden, Died 2 May 1980 (60 years) Oskarshamn Aiport, Sweden (place of residence at death Ryssby parish, Sweden)
If that can be achieved without introducing a property, that’s fine. If no new property is created, two other things must work:
- It must be possible (and not too difficult) to add the following information in Wikidata: that a person physically died at a certain place X, and the person’s place of residence at the time of death was Y. (This is relevant in countries where people’s places of residence – and every change in place of residence – are recorded by the government.)
- It must be possible to write templates (mallar in Swedish) so that they retrieve the Wikidata information, and the information is displayed in articles in the way I exemplified above: Johan Johansson was killed in a crash at an airport, but his place of residence was elsewhere.
If those things can be achieved without creating a new property, I would be happy with that. Jan Arvid Götesson (talk) 01:09, 8 February 2023 (UTC)
- @Esquilo@Ainali@BrokenSegue@ChristianKl@Infrastruktur@Larske@Salgo60@Tinker Bell: This discussion has come to an impasse. Since I know little about Wikidata (I am mainly a writer of Wikipedia articles) I would like to have a Yes/No answer to my question: If we do not create a new property, would it be easy to store the piece of information “place of resident registration at death” in Wikidata (perhaps using residence (P551), end cause (P1534) → death of subject (Q99521170), nature of statement (P5102) → de jure (Q132555) as suggested), and would it be easy to retrieve and display that information in an infobox in a biographical Wikipedia article using a template, side by side with the physical place of death in the same infobox? Thank you. Jan Arvid Götesson (talk) 22:32, 13 February 2023 (UTC)
- @Jan Arvid Götesson
- 1) As I stated you have it already in the source, example map of Swedish peoples graves with a coordinate AND with a reference from a church death record (Q10478639)
- 2) You get that information in the reference list in Wikipedia isnt that good enough see ref 4 sv:Oskar_Eklund
- video trying to explain my point
- - Salgo60 (talk) 22:53, 13 February 2023 (UTC)
- @Salgo60 Thank you for you answer. I am ignorant about technical things, and I must study the information you provide to understand it. Meanwhile, just to clarify, do you answer YES to my double question (the question being, can the information we have discussed easily be stored in Wikidata (and entered into Wikidata by people like me), and can it easily be retrieved from Wikidata and displayed in Wikipedia automatically? Jan Arvid Götesson (talk) 00:55, 14 February 2023 (UTC)
- @Jan Arvid Götesson
- Example Gulli Petrini (Q4972683)
- I would say her death is stated by the book with Swedish National Archive reference code (P5324) = SE/SSA/0011/F I/21 that is
- F for the death books and I guess !/21 is the physical books number
- the first part of the NAD = SE/SSA/0011 is identifying the archive for the churchbooks of a Swedish church parish --> Kungsholms parish (Q10550317)
- a search haswbstatement:"P5324=SE/SSA/0011" find the Swedish Church parish that has that churchbook
- When I design solutions I create en:Use cases for different stakeholders exemple
- 1) As an user I would like to see the death records that states the persons death i,.e. the en:primary source. That I feel we have today with Wikidata and a Wikidata driven template like Template:Infobox person/Wikidata (Q17534637)
- > can it easily be retrieved from Wikidata and displayed in Wikipedia
- isnt it the record from the registration book people would like to find?
- Maybe its easier if you call me +46-735152802
- - Salgo60 (talk) 01:46, 14 February 2023 (UTC)
- @Salgo60 Thank you for you answer. I am ignorant about technical things, and I must study the information you provide to understand it. Meanwhile, just to clarify, do you answer YES to my double question (the question being, can the information we have discussed easily be stored in Wikidata (and entered into Wikidata by people like me), and can it easily be retrieved from Wikidata and displayed in Wikipedia automatically? Jan Arvid Götesson (talk) 00:55, 14 February 2023 (UTC)
- @Jan Arvid Götesson In my opinion: No. And that's because the parishes we have is not where people are residing. I think it will, and should, cause a property constraint to give a warning if someone adds a parish as a value to that property. It's semantically not correct but would be squeezing the wrong kind of value in that field. That is why the suggestion that Tinker Bell, ChristianKl and Infrastruktur does not work and why their votes should be seen as invalid (as their counter suggestion is invalid). Ainali (talk) 17:50, 14 February 2023 (UTC)
- @Ainali I asked you above for examples for your "new constraints theory". I guess you speak about place of death (P20) as you understand Swedish what is the conclusion of the below sources?
- Example Gulli Petrini (Q4972683)
- domain experts Dictionary of Swedish National Biography ID (P3217) from the National Archives of Sweden (Q1724971) - writes 7193
- Example Gulli Petrini (Q4972683)
- @Ainali I asked you above for examples for your "new constraints theory". I guess you speak about place of death (P20) as you understand Swedish what is the conclusion of the below sources?
Född:1867-09-30 – Jakobs församling, Stockholms län Död:1941-04-08 – Kungsholm eller Ulrika Eleonora, Stockholms län
- the primary source church death record (Q10478639) --> Kungsholms kyrkoarkiv, Död- och begravningsböcker, SE/SSA/0011/F I/21 (1936-1942), bildid: 00026758_00225 page 251
- Row 105 column 6 says her address Scheeleg. 13 and column 19 says in Swedish Dödsort = death location and on her row it says in Swedish at home I hemmet
- the primary source church death record (Q10478639) --> Kungsholms kyrkoarkiv, Död- och begravningsböcker, SE/SSA/0011/F I/21 (1936-1942), bildid: 00026758_00225 page 251
- Jan is this sources good for you that she has died and what is the correct location place of death (P20) a
- what would you think is correct value in Wikidata?
- your suggested constraints what should it warn for?
- - Salgo60 (talk) 20:33, 14 February 2023 (UTC)
- @Ainali: Wikidata doesn't work in a way where the votes of people who disagree with how you think a property should be used are invalid.
- Why do you believe that someone who is registered in a parish isn't a resident in that parish? ChristianKl ❪✉❫ 01:26, 15 February 2023 (UTC)
- Oh, they may very well have their residence in that parish. However, the property residence (P551) should not have parishes as value. None of neither the English nor Swedish aliases suggest that. And the property constraints does not seem to allow it either, which is inline with the name. If we change this, then that property should also change name as it's meaning changes. Ainali (talk) 16:02, 17 February 2023 (UTC)
- @Ainali: Whether aliases suggest that is completely irrelevant. Aliases are not there to define the meaning of a property. If you look at the property description for residence, it's about where someone is a resident. If you think it should be renamed, feel free to bring that up on it's talk page. ChristianKl ❪✉❫ 21:26, 17 February 2023 (UTC)
- @Ainali: For me a parish is just a location with less good precision... If we dont have better precision then a parish is better than nothing. I think the "challenge" is more how to define residence (P551) that works with todays possibilities i.e. in my my video can we define what apartment and what windows with direction to the street the person lived in. With Gulli Petrini (Q4972683) we have an WD object for the street Scheelegatan (Q10663209) which is a start but how do we develop the property so that we can tell its the window 3 on the third floor....
- its ok with less good precision if we dont have better
- how do we define residence (P551) with a better "precision" so it works with todays new possibilities with VR, AR I feel is the challenge more than we get objects with less good precision
- @Jan Arvid Götesson: the suggestion place of resident registration' is useful if we should find the "official place" stating the fact but as said above maybe we already have this data in the sources - [my example map](https://w.wiki/6GYJ) of people in Sweden with a grave location AND an official registration in church death record (Q10478639)
- - Salgo60 (talk) 07:17, 19 February 2023 (UTC)
- @ChristianKl Sure, aliases does not define it. But what you seem to miss is that you cannot be a resident in one of these parishes any more than you can be a resident in a brand or a language. They are simply different types of items. Ainali (talk) 09:49, 19 February 2023 (UTC)
- @Ainali: For me a parish is just a location with less good precision... If we dont have better precision then a parish is better than nothing. I think the "challenge" is more how to define residence (P551) that works with todays possibilities i.e. in my my video can we define what apartment and what windows with direction to the street the person lived in. With Gulli Petrini (Q4972683) we have an WD object for the street Scheelegatan (Q10663209) which is a start but how do we develop the property so that we can tell its the window 3 on the third floor....
- @Ainali: Whether aliases suggest that is completely irrelevant. Aliases are not there to define the meaning of a property. If you look at the property description for residence, it's about where someone is a resident. If you think it should be renamed, feel free to bring that up on it's talk page. ChristianKl ❪✉❫ 21:26, 17 February 2023 (UTC)
- Oh, they may very well have their residence in that parish. However, the property residence (P551) should not have parishes as value. None of neither the English nor Swedish aliases suggest that. And the property constraints does not seem to allow it either, which is inline with the name. If we change this, then that property should also change name as it's meaning changes. Ainali (talk) 16:02, 17 February 2023 (UTC)
- @AinaliThanks for your reply. I use examples to make things clear. If a Wikipedia article were written about me after I die registered in my house in Sweden, you suggest that my ”place of resident registration at death” would be ”Stationsvägen 6, Ingelstad, Östra Torsås distrikt, Sweden” or possibly ”Ingelstad 16:5, Östra Torsås distrikt, Växjö kommun, Sweden” if we use the name of the property instead of the street address. (I am now talking about real estate ”property”, not Wikidata ”property”.)
- Do I understand correctly, or am I confused?
- I originally thought that parish/district would be a close enough piece of information for ”place of resident registration at death”. My idea was that “Östra Torsås distrikt, Sweden” would be enough to state where my ”place of resident registration at death” would presumably be, because Östra Torsås distrikt is an area of only 10 km times 10 km. But I am happy with your suggestion that the actual address or property should be included. Jan Arvid Götesson (talk) 05:21, 15 February 2023 (UTC)
- Agree that is my understanding the only odd thing with Swedish church Parishes is that we have a few of type non-territorial parishes (Q10533490) "formed independently of the geographical anchoring of the members" i.e. if we should do our homework we should maybe not use them for place of death (P20), we can see that the Swedish National Archive use e.g. The Royal Court Parish (Q10526665) see Claes Adolph Fleming (Q5733074) and SBL 14203
Död:1831-05-12 – Hovförsamlingen, Stockholms län
- Which I would say is odd... I can ask the SBL people how they do today the above article was published 1966
- Other user cases I can see that there is an interest to also in Wikidata have the street name and a coordinate of the "actual location" also in Wikidata
- I see Google Map develop in direction that you use your phone to locate were you are on a street and what buildings you can see and then if you are on Scheelegatan 13 in Stockholm and are interested in historical people you should see that Gulli Petrini (Q4972683) died/lived on the street
- maybe we need better support for pointing out a specific apartment/window from the street/name(identifier) of the apartment a person died in see my Scheelegatan movie
- In Sweden we have a historical book scanning project Swedish Literature Bank (Q10567910) and they would like to point on a map were August Strindberg (Q7724) died and then the church parish is not good enough
- I see Google Map develop in direction that you use your phone to locate were you are on a street and what buildings you can see and then if you are on Scheelegatan 13 in Stockholm and are interested in historical people you should see that Gulli Petrini (Q4972683) died/lived on the street
- Other user cases I can see that there is an interest to also in Wikidata have the street name and a coordinate of the "actual location" also in Wikidata
- - Salgo60 (talk) 06:02, 15 February 2023 (UTC)
- Which I would say is odd... I can ask the SBL people how they do today the above article was published 1966
- Comment residence (P551) is can not be used as it is too precise, it refers to a residence (Q699405) rather than a administrative territorial entity (Q56061). So a new property needs to be created anyway, regardless if it is "place of resident registration at death" or just "place of resident registration" with the qualifier end cause (P1534) => death of subject (Q99521170). /ℇsquilo 11:27, 15 February 2023 (UTC)
- @ℇsquilo: That claim is just straightforwardly wrong. If you look at the property examples of residence (P551), it has Zhongtian Mao (Q102317003) residence (P551) Zhenjiang (Q57958) where Zhenjiang (Q57958) is an administrative territorial entity (Q56061). Why not look at the actual property examples before making mistaken claims? ChristianKl ❪✉❫ 21:24, 17 February 2023 (UTC)
- @ChristianKl Zhenjiang (Q57958) is also an instance of big city (Q1549591). If it only was an administrative territorial unit, it would give a constraint warning. Did you look at the property constraints before making mistaken claims? Ainali (talk) 09:54, 19 February 2023 (UTC)
- I did look at the constraints and they have geographic region (Q82794) which is described as "2D or 3D defined space on something, mainly in terrestrial and astrophysics sciences". "administrative territorial entity" do fit under that category: administrative territorial entity (Q56061)->human-geographic territorial entity (Q15642541)->territory (Q4835091)->geographic region (Q82794). Certainly, the Pariash that we are talking about are "2D defined spaces on earth". ChristianKl ❪✉❫ 14:31, 19 February 2023 (UTC)
- @ChristianKl Zhenjiang (Q57958) is also an instance of big city (Q1549591). If it only was an administrative territorial unit, it would give a constraint warning. Did you look at the property constraints before making mistaken claims? Ainali (talk) 09:54, 19 February 2023 (UTC)
- @ℇsquilo: That claim is just straightforwardly wrong. If you look at the property examples of residence (P551), it has Zhongtian Mao (Q102317003) residence (P551) Zhenjiang (Q57958) where Zhenjiang (Q57958) is an administrative territorial entity (Q56061). Why not look at the actual property examples before making mistaken claims? ChristianKl ❪✉❫ 21:24, 17 February 2023 (UTC)
- Oppose. Not needed, use P551 with appropriate qualifiers. Maxime Ravel (talk) 05:37, 1 July 2023 (UTC)
bust/waist/hip measurements Edit
chest measurement Edit
Description | circumfence of bust of somebody |
---|---|
Represents | bust (Q100990168) |
Data type | Quantity |
Domain | humanoid (Q502931), fictional humanoid (Q28020127) |
Allowed values | number |
Allowed units | inches, centimeters |
Example 1 | Roos van Montfort (Q15881468) -> 34 inch [1] |
Example 2 | Astolfo (Q106191885) -> 71 centimeter [2] |
Example 3 | MISSING |
Planned use | Similar to height (P2048) and mass (P2067), this data will be listed for real individuals if it is publicly known and should be qualified with a date as physical characteristics like them are bound to change in an individual over time. B/W/H measurements specifically would be far more likely to see use in the realm of fictional characters. |
See also | height (P2048), mass (P2067), Wikidata:Property proposal/Cup size, Wikidata:Property proposal/body measurements |
Wikidata project | WikiProject Anatomy (Q8487304), Wikidata property related to erotica or pornography (Q53671196) |
waist measurement Edit
Description | circumfence of waist of somebody |
---|---|
Represents | waist (Q236232) |
Data type | Quantity |
Domain | humanoid (Q502931), fictional humanoid (Q28020127) |
Allowed values | number |
Allowed units | inches, centimeters |
Example 1 | Roos van Montfort (Q15881468) -> 24 inch [3] |
Example 2 | Astolfo (Q106191885) -> 59 centimeter [4] |
Example 3 | MISSING |
Planned use | Similar to height (P2048) and mass (P2067), this data will be listed for real individuals if it is publicly known and should be qualified with a date as physical characteristics like them are bound to change in an individual over time. B/W/H measurements specifically would be far more likely to see use in the realm of fictional characters. |
See also | height (P2048), mass (P2067), Wikidata:Property proposal/Cup size, Wikidata:Property proposal/body measurements |
Wikidata project | WikiProject Anatomy (Q8487304), Wikidata property related to erotica or pornography (Q53671196) |
hip measurement Edit
Description | circumfence of hip of somebody |
---|---|
Represents | hip (Q193818) |
Data type | Quantity |
Domain | humanoid (Q502931), fictional humanoid (Q28020127) |
Allowed values | number |
Allowed units | inches, centimeters |
Example 1 | Roos van Montfort (Q15881468) -> 36 inch [5] |
Example 2 | Astolfo (Q106191885) -> 73 centimeter [6] |
Example 3 | MISSING |
Planned use | Similar to height (P2048) and mass (P2067), this data will be listed for real individuals if it is publicly known and should be qualified with a date as physical characteristics like them are bound to change in an individual over time. B/W/H measurements specifically would be far more likely to see use in the realm of fictional characters. |
See also | height (P2048), mass (P2067), Wikidata:Property proposal/Cup size, Wikidata:Property proposal/body measurements |
Wikidata project | WikiProject Anatomy (Q8487304), Wikidata property related to erotica or pornography (Q53671196) |
Motivation Edit
Similar to height (P2048) and mass (P2067), this data will be listed for real individuals if it is publicly known and should be qualified with a date as physical characteristics like them are bound to change in an individual over time. B/W/H measurements specifically would be far more likely to see use in the realm of fictional characters. OmegaFallon (talk) 17:16, 31 January 2023 (UTC)
Addition: This should be three separate properties, not one single property. OmegaFallon (talk) 22:50, 1 February 2023 (UTC)
Discussion Edit
- Oppose no examples given, no units, not structured data BrokenSegue (talk) 17:26, 31 January 2023 (UTC)
- Ideally there shouldn't be three different measurements stored as a single string. You also do need examples. -wd-Ryan (Talk/Edits) 19:57, 31 January 2023 (UTC)
- Maybe you should ping Wikidata:WikiProject Women, Wikidata:WikiProject Anatomy, Wikidata property related to erotica or pornography (Q53671196). 2A01:CB14:D52:1200:8DA3:FC51:5E29:9C71 12:32, 1 February 2023 (UTC)
- Agreed, though I do want to note that all of these measurements do also apply to males and male characters, and everyone regardless of gender. No intentions of anything female-specific with my proposal here. OmegaFallon (talk) 22:42, 1 February 2023 (UTC)
- Previous proposal: Wikidata:Property proposal/body measurements. Support only as three properties.--GZWDer (talk) 15:17, 1 February 2023 (UTC)
- Can I be honest? I agree completely but I didn't feel like going through the effort of submitting three separate proposals. OmegaFallon (talk) 22:41, 1 February 2023 (UTC)
- you can make three submissions at once by just copying and pasting the above template. we can't have the data represented as you suggested. if you aren't willing to put in the effort of making 3 proposals are you willing to enter in/import hundreds/thousands of values for these properties? BrokenSegue (talk) 22:43, 1 February 2023 (UTC)
- Apologies for striking a nerve. I've separated the proposal boxes, but I feel like discussion for these should be unified. OmegaFallon (talk) 20:32, 2 February 2023 (UTC)
- you can make three submissions at once by just copying and pasting the above template. we can't have the data represented as you suggested. if you aren't willing to put in the effort of making 3 proposals are you willing to enter in/import hundreds/thousands of values for these properties? BrokenSegue (talk) 22:43, 1 February 2023 (UTC)
- Can I be honest? I agree completely but I didn't feel like going through the effort of submitting three separate proposals. OmegaFallon (talk) 22:41, 1 February 2023 (UTC)
- Comment Note that the current convention is to use three perimeter (P2547) claims, with applies to part (P518) qualifiers set to bust (Q100990168), waist (Q236232) and hip (Q193818). This feels a bit messy to me, and it feels odd to use these to describe someone's "perimeter". However, it 'works', so I am not entirely convinced about the need for the proposed property. As others have suggested, if this is to be created, it should be as three separate properties. Yirba (talk) 15:53, 2 February 2023 (UTC)
- I've been editing Wikidata for only a short while, but honestly, you can pretty much get anything to "work" on here if you're willing to stretch the definition of "work", and here I do think that's a stretch. I guess to be fair, one could have publicly available measurements for any part of their body, and it would be ridiculous to create properties for all of them. On the other hand, though, these three measurements are a bit more noteworthy than any other arbitrary measurement of a person's body. OmegaFallon (talk) 20:32, 2 February 2023 (UTC)
- that is a pretty accurate understanding of wikidata. we could replace all properties with one if we were willing to use enough qualifiers. My main question is whether there are enough reliable sources on these figures. Especially since presumably as people age these numbers change a lot. BrokenSegue (talk) 20:56, 2 February 2023 (UTC)
- A reference requirement is a given, but I think also requiring an "as of: [date]" qualifier is a good idea too. As for reliable sources, I can't say. This isn't exactly something that comes up in news articles, but then again, where would we find someone's height or weight? An online bio page or something of the sort I guess. OmegaFallon (talk) 21:02, 2 February 2023 (UTC)
- height and weight are also used for non-humans i believe. and (medicore) references for height are plentiful. BrokenSegue (talk) 21:21, 2 February 2023 (UTC)
- "as people age these numbers change a lot" - we does not record the actual body measurements of someone; we only record how sources said about them. GZWDer (talk) 21:25, 2 February 2023 (UTC)
- yes I understand that. but people have a bad habit of adding information with no dates (sources often won't specify) BrokenSegue (talk) 21:52, 2 February 2023 (UTC)
- "as people age these numbers change a lot" - we does not record the actual body measurements of someone; we only record how sources said about them. GZWDer (talk) 21:25, 2 February 2023 (UTC)
- height and weight are also used for non-humans i believe. and (medicore) references for height are plentiful. BrokenSegue (talk) 21:21, 2 February 2023 (UTC)
- A reference requirement is a given, but I think also requiring an "as of: [date]" qualifier is a good idea too. As for reliable sources, I can't say. This isn't exactly something that comes up in news articles, but then again, where would we find someone's height or weight? An online bio page or something of the sort I guess. OmegaFallon (talk) 21:02, 2 February 2023 (UTC)
- that is a pretty accurate understanding of wikidata. we could replace all properties with one if we were willing to use enough qualifiers. My main question is whether there are enough reliable sources on these figures. Especially since presumably as people age these numbers change a lot. BrokenSegue (talk) 20:56, 2 February 2023 (UTC)
- I've been editing Wikidata for only a short while, but honestly, you can pretty much get anything to "work" on here if you're willing to stretch the definition of "work", and here I do think that's a stretch. I guess to be fair, one could have publicly available measurements for any part of their body, and it would be ridiculous to create properties for all of them. On the other hand, though, these three measurements are a bit more noteworthy than any other arbitrary measurement of a person's body. OmegaFallon (talk) 20:32, 2 February 2023 (UTC)
- Support FANZA AV actress ID (P9781) would be a good reference for AV idol (Q1079215). Laftp0 (talk) 05:41, 4 February 2023 (UTC)
- Oppose given that no effort was made into actually making proposals for each one with a name and description. perimeter (P2547) along with applies to part (P518) should do the job. ChristianKl ❪✉❫ 18:00, 7 February 2023 (UTC)
- I have added descriptions to each requuest. This is a common figure in fashion.--GZWDer (talk) 19:10, 10 February 2023 (UTC)
- Why is the name measurement and not circumference? Both bust, waist and hip are anatomical features that have a different circumference at different points and the current description says nothing about the specific poiint where it's measured.
- Apart from that number is not a datatype in Wikidata. ChristianKl ❪✉❫ 20:12, 10 February 2023 (UTC)
- I have added descriptions to each requuest. This is a common figure in fashion.--GZWDer (talk) 19:10, 10 February 2023 (UTC)
- Support --Trade (talk) 16:12, 30 May 2023 (UTC)
cup size Edit
Description | size characteristics of a bra |
---|---|
Represents | bra size (Q2608071) |
Data type | Quantity |
Example 1 | Roos van Montfort (Q15881468)cupsize<B cup> [7] |
Example 2 | Peta Todd (Q2286931)cupsize<F cup> [8] |
Example 3 | Noa Eikawa (Q27917706)cupsize<B cup> |
Example 4 | Denice Lam (Q65312947)cupsize<D cup> [9] |
Example 5 | Cathryn Li (Q18683006)cupsize<C cup> [10] |
Example 6 | Sabrina Pai (Q8957832)cupsize<B cup> (in 2006) [11] |
See also | Wikidata:Property proposal/bust/waist/hip measurements |
Motivation Edit
Previous discussion: Wikidata:Property proposal/Cup size. Response to some oppositions and criticisms:
- I am not restricted it to use in porn actress only. In some countries cup size is not considered sensitive/sexist/misogynistic; for example they are commonly discussed (by reliable sources) in Taiwan.
- (Response to Special:Diff/1823929462) This does not mean we need a property for penis size unless it is commonly discussed in reliable sources.
- "It's out of scope for Wikidata to store all clothing & body measurements" - as it is commonly used in some Wikipedias it is useful to have such information.
- "the value is an extremely variable quantity anyway, and can depend massively on factors on the manufacturer's side" - We only store how sources said about them.
--GZWDer (talk) 19:54, 10 February 2023 (UTC)
Discussion Edit
- Oppose Even if I lived in Taiwan I would see no compelling case made here.
- Oppose The description of the property states that it is “the size characteristics of a bra”. However, the property is aimed at describing the woman’s breast size which I find sexist. After all, the opposition in the previous proposal pointed to this issue. M.roszkowski (talk) 17:31, 12 April 2023 (UTC)
- It is not the job of Wikidata to ensure that all data adheres to sex negative norms. --Trade (talk) 15:57, 30 May 2023 (UTC)
- Oppose We really don't need such information on Wikidata, in my opinion. --Gymnicus (talk) 08:43, 10 May 2023 (UTC)
- Support The fact that all the oppose is some variant of "i don't like this subject" is quite telling. --Trade (talk) 15:53, 30 May 2023 (UTC)
- Oppose for the purely technical reason that unsourced additions of this property cannot always be prevented all the time. Mahir256 (talk) 16:33, 31 May 2023 (UTC)
Picture of this person doing his job Edit
Description | picture of a person in action, especially sportsmen, visual artists, musicans, actors. P18 is normally used for portraits |
---|---|
Data type | Commons media file |
Domain | Q5 |
Example 1 | Chiara Kreuzer (Q5331554) = 20190226 Seefeld SJ 4720.jpg |
Example 2 | Jakob Eiksund Sæthre (Q87721657) → File:20200222_FIS_NC_COC_Eisenerz_PRC_HS109_Men_Jakob_Eiksund_Saethre_850_4504.jpg |
Example 3 | María Ólafsdóttir (Q19264382) = file:20150516 ESC 2015 Maria Olafs 9813.jpg |
Example 4 | Cornelia Kreuter (Q87345351) = file:20190315 Dancing Stars 1100.jpg |
Example 5 | Lars Ulrich (Q106193) = file:Lars Ulrich live in London 2008-09-15.jpg |
Example 6 | Angela Merkel (Q567) = file:President Joe Biden meets with German Chancellor Angela Merkel at the G7 Summit.jpg |
Source | Commons:Category:People |
See also | subproperty of Property:P18 ; Property:P109, Property:P1801, Property:P1442, Property:P5775 |
Motivation Edit
In general, these are better stored in a separate property than in image (P18). The image could be used in wikidata infoboxes on Commons similar to Property:P109, Property:P1801, Property:P1442, Property:P5775 --Z thomas (talk) 22:28, 22 March 2023 (UTC)
Discussion Edit
- Support --M2k~dewiki (talk) 23:32, 22 March 2023 (UTC)
- Oppose Duplicates information which is more within the scope of Wikimedia Commons (and Commons categories often already have Wikidata items) -عُثمان (talk) 23:51, 27 March 2023 (UTC)
- This isn't only the scope of commons.
- It fits perfectly to the scope of wikidata to provide information, it works also with pictures have a look at properties like p109 or p1442 Z thomas (talk) 12:32, 24 April 2023 (UTC)
- Of course there is a use at commons for example in the Infobox like C:Category:St. Maria Meeresstern (Werder (Havel)) - three different images of one object Z thomas (talk) 05:22, 25 April 2023 (UTC)
- Oppose I personally don't see the benefit of the property. I can't understand the intention of the image then being displayed in the Wikidata info box either. You have gallery pages on Commons to show stuff like that. --Gymnicus (talk) 08:48, 10 May 2023 (UTC)
- The images are shown in the wikidata Infobox. This is shown in the commons cat, the gallery pages is something different Z thomas (talk) 21:04, 6 June 2023 (UTC)
- For example the usage of many different pictures in the wikidata Infobox C:Category:Berlin Greetings Z thomas (talk) 21:07, 6 June 2023 (UTC)
- The images are shown in the wikidata Infobox. This is shown in the commons cat, the gallery pages is something different Z thomas (talk) 21:04, 6 June 2023 (UTC)
- Support If possible, the image (P18) should always be a portrait. But why not also a picture of the person in his or her typical working environment (athlete, dancer, actress). Similar to buildings, several views are useful (nighttime view (P3451), image of design plans (P3311), image of interior (P5775), schematic (P5555), aerial view (P8592),). --sk (talk) 15:20, 18 June 2023 (UTC)
- Support --Lutzto (talk) 16:44, 20 June 2023 (UTC)
- Support --Derbrauni (talk) 12:14, 3 July 2023 (UTC)
- Support Seems quite reasonable to me. For many professions and activities you cannot see the face of the person when this person is doing their job, - at the same time it's quite obvious to have a picture of the person dancing if they are a dancer. Ideally infoboxes could allow customers to switch between these two images. Андрей Романенко (talk) 15:08, 29 August 2023 (UTC)
Represents | taboo name (Q64026473) |
---|---|
Data type | String |
Domain | human (Q5) |
Example 1 | Oda Nobunaga (Q171411)→信長 |
Example 2 | Toyotomi Hideyoshi (Q187550)→秀吉 |
Example 3 | Tokugawa Ieyasu (Q171977)→家康 |
Wikidata project | WikiProject Names (Q15884604) |
Motivation Edit
To accurately describe the names of Japanese warlords. In addition to the "courtesy name (P1782)" already in the property, the names of Japanese military commanders have "uji"[13] and "kabane"[14]. --影佑樹 (talk) 17:31, 19 June 2023 (UTC)
Discussion Edit
- Notified participants of WikiProject Names, Notified participants of WikiProject Japan - Valentina.Anitnelav (talk) 21:23, 26 June 2023 (UTC)
- Oppose. posthumous name (P1786), art name (P1787), etc. can be used as a taboo name (Q64026473). It is not a basic attribute and can be simply replaced by given name (P735) in the Japanese warlord characters. --PexEric (talk) 09:11, 5 July 2023 (UTC)
- posthumous name (P1786) is the name after death, and art name (P1787) is the name different from the real name. 織田信長 real name 平 朝臣 織田 上総介 三郎 信長。uji (Q2575910) myōji (Q69634220) Kabane (Q1664099) East Asian government official (Q11452125) Kemyō (Q10898440) 諱。--影佑樹 (talk) 13:14, 5 July 2023 (UTC)
elected on Edit
Description | Date when a person was elected to a position held (P39), in difference to start time (P580) (= taking office (Q28530236)). elected in (P2715) cannot always be applied. |
---|---|
Data type | Point in time |
Example 1 | Pope Francis (Q450675)position held (P39)Archbishop of Buenos Aires (Q104786984) |
Example 2 | Walther Bringolf (Q1597413)position held (P39)Mayor of Schaffhausen (Q118706571) |
Example 3 | Winston Churchill (Q8016)position held (P39)Prime Minister of the United Kingdom (Q14211) |
Planned use | Update these informations for politicians |
Expected completeness | always incomplete (Q21873886) |
See also | start time (P580), elected in (P2715) |
Single-value constraint | yes |
Motivation Edit
(Setze deine Begründung für diese Eigenschaft hier her) – The preceding unsigned comment was added by Rerumscriptor (talk • contribs) at 11:40, June 26, 2023 (UTC).
Discussion Edit
- Comment I'm not too familiar with this domain but I can see how this might be needed from the description. Thinking about it. ArthurPSmith (talk) 14:33, 27 June 2023 (UTC)
- Oppose: why not use instead P793, with a P585 qualifier? Maxime Ravel (talk) 05:50, 1 July 2023 (UTC)
- I think this gets quite difficult/is hard to understand when a person held the same position several times with a break between. Rerumscriptor (talk) 20:00, 17 July 2023 (UTC)
ManyVids ID Edit
Description | identifier for a person on the ManyVids website |
---|---|
Represents | human (Q5) |
Data type | External identifier |
Domain | Q44506342 |
Example 1 | Cory Chase (Q41733019)→https://www.manyvids.com/Profile/1001763795/corychasexxx/Store/Videos/ |
Example 2 | Natasha Nice (Q2087557)→https://www.manyvids.com/Profile/1000592171/natasha-nice/Store/Videos/ |
Example 3 | Betty Foxxx (Q122271788)→https://www.manyvids.com/Profile/1000793837/bettyfoxxx/Store/Videos/ |
Planned use | Add a link to the porn star's profile on ManyVids |
Formatter URL | https://www.manyvids.com/Profile/$1 |
Motivación Edit
Website for the sale of porn videos and movies used by porn stars, alternative to OnlyFans. ManyVids has 10 million visitors per month.Vivaelcelta (talk) 05:37, 7 September 2023 (UTC)
Discussion Edit
- Conditional support I think the property value should be just the numeric ID. For example, the ManyVids ID for Cory Chase should be
1001763795
. The URL formatter could then behttps://www.manyvids.com/Profile/$1/_/Store/Videos
. Yirba (talk) 13:25, 8 September 2023 (UTC) - Comment Yirba Thanks. Good contribution.--Vivaelcelta (talk) 14:17, 8 September 2023 (UTC)
LoverFans ID Edit
Description | identifier for a person on the LoverFanswebsite |
---|---|
Represents | human (Q5) |
Data type | External identifier |
Domain | LoverFans (Q117066117) |
Example 1 | Jordi El Nino Polla (Q35831601)→https://loverfans.com/jordienp |
Example 2 | Apolonia Lapiedra (Q23695802)→https://loverfans.com/Apolonia |
Example 3 | Pamela Sánchez (Q116978995)→https://loverfans.com/Pamela_Sanchez |
Planned use | Add a link to the porn star's profile on LoverFans |
Formatter URL | https://loverfans.com/$1 |
Motivación Edit
Spanish adult content subscription service mostly used by porn stars, alternative to OnlyFans. In 2021, LoverFans had 14.000 creators and 200.000 users. Vivaelcelta (talk) 05:44, 7 September 2023 (UTC)
Discussion Edit
User account Edit
Identifier Edit
Prisoner number Edit
Description | Prisoner number |
---|---|
Represents | inmate number (Q40976232) |
Data type | String |
Example 1 | Maximilian Kolbe (Q153850) → 16670 |
Example 2 | Witold Pilecki (Q315691) → 4859 |
Example 3 | Władysław Bartoszewski (Q381185) → 4427 |
Example 4 | Czesława Kwoka (Q5202138) → 26947 |
Example 5 | Mala Zimetbaum (Q276062) → 19880 |
Example 6 | Otto Küsel (Q113050) → 2 |
Planned use | Populate this property with identifiers from various sources. |
Expected completeness | eventually complete (Q21873974) |
Motivation Edit
This property can be used to store the prisoner number from Nazi German concentration camps. It should store multiple values, as some people had more than one number, e.g. Otto Küsel (Q113050) had #979 in Sachsenhausen concentration camp (Q154498) and #2 in Auschwitz (Q7341). LimaMario (talk) 22:09, 25 July 2022 (UTC)
Discussion Edit
- @LimaMario: Seems like a good idea, but what's your source for this information? Is there a website or other reference we can confirm these numbers? ArthurPSmith (talk) 16:33, 27 July 2022 (UTC)
- Datatype changed to string as it is not unique.--GZWDer (talk) 21:58, 27 July 2022 (UTC)
- What’s the reliable source? --Polarlys (talk) 19:04, 2 August 2022 (UTC)
- As reliable sources I do have [15] Norsk digitalt fangearkiv 1940-1945 - Fanger.no for norwegian political and war prisoners 1940 - 1945, for civilian prisoners in norway several prisoners name protocols can be found at [16]https://www.digitalarkivet.no/ for concentration camps I can find for instance {{Q|Q312478== [17]https://www.kz-gedenkstaette-neuengamme.de/en/history/death-register/. Also pinging @ArthurPSmith: Pmt (talk) 19:47, 2 July 2023 (UTC)
- Not sure what to make of this idea. eventually complete (Q21873974) doesn’t seem realistic. If implemented, it should only be used as a qualifier (property scope constraint (Q53869507) = as qualifier (Q54828449) together with place of detention (P2632)) Notified participants of WikiProject Victims of National Socialism --Emu (talk) 09:52, 18 August 2022 (UTC)
- Comment What qualifiers would be used here? Or should this be used as a qualifier? BrokenSegue (talk) 04:12, 14 September 2022 (UTC)
- Support with qualifier of a dataset/institution Germartin1 (talk) 04:04, 12 November 2022 (UTC)
- Support also with qualifier of a dataset/institution. For norwegian prisoners during WWII prisoners camp number are registered at Fanger.no Pmt (talk) 15:45, 21 March 2023 (UTC)
- Comment the property name is extremely vague and doesn't explain what this property identifies. The subject item should be the name of the database that this number comes from. What is the applicable 'stated in' value? AdamSeattle (talk) 15:55, 24 March 2023 (UTC)
@LimaMario, ArthurPSmith, Emu, BrokenSegue, Germartin1, Pmt: I would be happy to create this property if you can come up with an example statement where this property is used as a qualifier to another statement. Harej (talk) 18:06, 2 July 2023 (UTC)
- @Harej I don’t think that this proposal is ready so I removed this status. The question of BrokenSegue is still unanswered: Should it be something like
- Otto Küsel (Q113050)place of detention (P2632)Sachsenhausen concentration camp (Q154498)
"prisoner number""979" (that would be my choice) or indeed - Otto Küsel (Q113050)"prisoner number""979"
place of detention (P2632)Sachsenhausen concentration camp (Q154498) (that seems to be the idea of Germartin1 and Pmt although I’m not 100% positive if I understand them right)
- Otto Küsel (Q113050)place of detention (P2632)Sachsenhausen concentration camp (Q154498)
- --Emu (talk) 19:17, 2 July 2023 (UTC)
- @Harej I do not quite understand what you fully require here. My support for this proposal as a qualifier si based upon norwegian poitical and war prisoners listed in Q96105649. Here I can find Trygve Bratteli (Q326587) having place of detention (P2632) Sachsenhausen concentration camp (Q154498) with 65663 as prisoner number, further Grini detention camp (Q637411) with prisoner numer 4533. There are many sources on NB.no, Digitalarkivet.no and Fanger.no for norwegian citizens. Pmt (talk) 19:23, 2 July 2023 (UTC)
- Support This is interesting because the numbers are not unique, we have no single database, this is a global practice that ought to apply to many prisons, and because I am not aware of any community like a "WikiProject Incarcerated Persons" that curates this, despite the audience interest in the topic. While I think the numbers need to have a reference or some explanation of the source, and they ought also to say the date and place of incarceration because those can change during an incarceration term, I think we can do this. Bluerasberry (talk) 14:58, 1 August 2023 (UTC)
- Support Seems very helpful.StarTrekker (talk) 04:40, 10 August 2023 (UTC)
Sens critique contributor ID Edit
Description | identifier for a contributor on Sens critique |
---|---|
Represents | SensCritique (Q16676060) |
Data type | External identifier |
Domain | human (Q5) |
Example 1 | Clément Mouille (Q77974330) → Clment_Nosferalis |
Example 2 | Nicolas Hoizey (Q116003404) → nhoizey |
Example 3 | Éric Schwald (Q116001232) → Sergent_Pepper |
Formatter URL | https://www.senscritique.com/$1 |
See also | SensCritique work ID (P10100) |
Notified participants of WikiProject France. 92.184.124.230 23:39, 3 January 2023 (UTC)
- @Sir Lothar, Jsamwrites, Ontogon, Floyd-out, Rockpeterson: who supported the creation related to works. 92.184.124.230 23:45, 3 January 2023 (UTC)
- @Wallacegromit1, Wd-Ryan, Trivialist, Poslovitch: 92.184.124.230 23:46, 3 January 2023 (UTC)
- @Kirilloparma, Jean-Frédéric: 92.184.124.230 23:47, 3 January 2023 (UTC)
- @Wallacegromit1, Wd-Ryan, Trivialist, Poslovitch: 92.184.124.230 23:46, 3 January 2023 (UTC)
- Support Trivialist (talk) 02:26, 4 January 2023 (UTC)
- Weak support external identifier. For transparency reasons, I support linking Wikidata items to this identifier. However, I am not very sure about the working of contributions to the SensCritique. Do contributors need to share their official names? Is it similar to official journalists of newspapers/magazines? John Samuel (talk) 11:44, 4 January 2023 (UTC)
- Comment why and what is the value here? is it even compliant with privacy rules, inluding but not limited to GDPR and Wikidata:Living people. More pragmatically, how many item would be concerned? (I see that the IP had to create the 3 items in example, not sure they even meet Wikidata:Notability criteria). Cheers, VIGNERON (talk) 18:17, 4 January 2023 (UTC)
- I have the same doubts as VIGNERON. Sir Lothar (talk) 17:24, 17 January 2023 (UTC)
- Oppose Agree with Vigneron. Jean-Fred (talk) 21:20, 28 January 2023 (UTC)
Pennsylvania State Senate ID Edit
Description | identifier for a Pennsylvania State senator |
---|---|
Represents | member of the Pennsylvania State Senate (Q18199902) |
Data type | External identifier |
Domain | human (Q5) |
Example 1 | Roxanne Jones (Q7372365) → 4835 |
Example 2 | Robert Adams, Jr. (Q7341350) → 2474 |
Example 3 | James C. Greenwood (Q6130715) → 4318 |
Source | https://www.legis.state.pa.us/cfdocs/legis/BiosHistory/index.cfm |
External links | Use in sister projects: [ar] • [de] • [en] • [es] • [fr] • [he] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt]. |
Planned use | Adding to existing legislator items, aiding in creation of new items, replacing generic described at URL (P973) usages |
Number of IDs in source | ~1,520 |
Expected completeness | eventually complete (Q21873974) |
Implied notability | Wikidata property for an identifier that suggests notability (Q62589316) |
Formatter URL | https://www.legis.state.pa.us/cfdocs/legis/BiosHistory/MemBio.cfm?ID=$1 |
Robot and gadget jobs | would be a good candidate for Mix 'n' Match |
Single-value constraint | yes |
Distinct-values constraint | yes |
Motivation Edit
Official database of the Pennsylvania State Senate (Q2269864) with historic legislator biographies. Note that there is a separate database for members of the Pennsylvania House of Representatives (Q2145217), which will probably require a separate property (e.g. James C. Greenwood (Q6130715) has a Senate ID of 4318 and Representative ID of 396). Both databases would add value to Wikidata. -Animalparty (talk) 04:31, 9 February 2023 (UTC)
Discussion Edit
Support Looks good. Andrew Gray (talk) 13:38, 13 February 2023 (UTC)
- Hold up: the source/ formatter URL has since changed (now https://www.library.pasen.gov/people/view-all) and complicating things even more, I've realized that this list seems only to include former members: currently serving senators are at this list, with a different formatter URL, and the ID numbering is not person-specific (e.g. the ID# 1764 for a current senator does not correspond to the same person in the historic database). I'm wondering if there might be a better way to link both current and former senators, without needing to create multiple properties just (this issue of different IDs for current and former members also applies to the House of Representatives). I'd rather get more critical feedback, and it might be a good idea to shelve this discussion until more clarity is revealed. -Animalparty (talk) 05:53, 19 February 2023 (UTC)
Brazzers ID Edit
Description | identifier for a pornographic actor on Brazzers |
---|---|
Represents | Brazzers (Q903343) |
Data type | External identifier |
Domain | human (Q5) |
Example 1 | Alyssia Kent (Q56473904) → 13743 |
Example 2 | Jessa Rhodes (Q19750471) → 4979 |
Example 3 | Kendra Lust (Q18818577) → 2617 |
Source | https://www.brazzers.com/pornstars |
Number of IDs in source | 2.681 |
Formatter URL | https://www.brazzers.com/pornstar/$1/_ |
@Thierry Caro: FYI. 92.184.107.134 04:52, 16 March 2023 (UTC)
Discussion Edit
- Comment The name at the end is unnecessary if you make the formatter URL this: https://www.brazzers.com/pornstar/$1/_ -wd-Ryan (Talk/Edits) 19:28, 16 March 2023 (UTC)
- Support. But only with the modification Wd-Ryan suggested. Thierry Caro (talk) 19:48, 16 March 2023 (UTC)
- @Thierry Caro, Wd-Ryan: done. 92.184.105.109 04:33, 17 March 2023 (UTC)
- Comment I wonder if the name should be "Brazzers pornstar ID" to distinguish it from a video ID, category ID, etc. It's worth noting that the IDs are shared with other sites operated by Aylo. For instance, Alexis Fawx has the ID 3911 whether on Brazzers, Digital Playground or Reality Kings. I wonder if this ID should be for Brazzers specifically or more general. Yirba (talk) 20:43, 19 March 2023 (UTC)
- Agreed, they have many separate IDs, should be distinguished. -wd-Ryan (Talk/Edits) 20:52, 19 March 2023 (UTC)
- @Trade: I would like to see this property created, but before marking this as ready, I would appreciate it if you could please address my comments. Thanks. Yirba (talk) 17:13, 3 June 2023 (UTC)
Bulletin of the American Astronomy Society Obituary ID Edit
Description | unique ID for an obituary in the Bulletin of the American Astronomy Society |
---|---|
Represents | Bulletin of the American Astronomical Society (Q1105325) |
Data type | External identifier |
Domain | human (Q5) (dead ones, scientists/astronomers) |
Example 1 | Jean-Pierre Swings (Q114896935)Obituary ID from BAAS832ef80f |
Example 2 | Peter Gierasch (Q115768005)Obituary ID from BAAS6d900b5a |
Example 3 | Terence Dickinson (Q7701885)Obituary ID from BAASa54cc2dc |
Planned use | External link to necrology on frwiki articles. |
Expected completeness | eventually complete (Q21873974) |
Formatter URL | https://doi.org/10.3847/25c2cfeb.$1 |
Applicable "stated in"-value | Bulletin of the American Astronomical Society (Q1105325) |
Wikidata project | Astronomy |
Motivation Edit
The Bulletin of AAS contains dozens of obituaries of scientists/astronomers. The addition of this identifier would allow, in the future, to use them to source wikipedia articles. It gives access to the birth date, place of birth, death date, place of death of the people. --Gabon100 (talk) 15:43, 4 April 2023 (UTC)
Notified participants of WikiProject Astronomy
Discussion Edit
- Comment Maybe it would be better to use
datatype, for example Richard Alan Schwartz (Q113711477)Obituary from BAASRichard A. Schwartz (1952–2020) (Q113711487). However, a property creation seems necessary to be able to add the link on Wikipedia via lua wikibase api. — Metamorforme42 (talk) 15:17, 30 March 2023 (UTC)item
- The journal has 7000 article entries on Wikidata of which 5 are obituaries. There are however 12 000 obituary articles in total. So if we have items for those anyway, using the item datatype makes sense, but only if as a general property. Currently described by source (P1343) serves this purpose. There's a constraint on the DOI number property that it can't be used on humans, that's worth keeping IMO, which means it is not an alternative here. Infrastruktur (talk) 18:07, 21 May 2023 (UTC)
HAL non-registered author ID Edit
Description | identifier for a non-registered author on HAL |
---|---|
Represents | HAL (Q3144107) |
Data type | External identifier |
Domain | human (Q5) |
Example 1 | Baptiste Mélès (Q48627667) → 5713 |
Example 2 | Dominique Manchon (Q102501397) → 850095 |
Example 3 | Laurence Plazenet (Q3218927) → 1042199 |
Source | https://hal.science/search/index/q/*/authIdHal_i |
Formatter URL | https://hal.science/search/index/q/*/authIdHal_i/$1 |
See also | P4450, P6023 |
Notified participants of WikiProject France. Nomen ad hoc (talk) 14:47, 18 April 2023 (UTC).
- Discussion
- Comment for confirmation: given that HAL author ID (P4450) covers authors registered on HAL, are we sure that this property covering non-registered authors has disambiguated IDs? I mean, does this numeric IDs refer to one researcher or to one name (that can belong to 2+ homonyms)? --Epìdosis 20:02, 18 April 2023 (UTC)
XWord Info author ID Edit
Description | identifier for a New York Times crossword (also variety or acrostic) puzzle constructor on XWord Info |
---|---|
Represents | XWord Info (Q100898281) |
Data type | External identifier |
Example 1 | Erik Agard (Q94697002) → Erik+Agard |
Example 2 | Emily Cox (Q5372122) → Emily+Cox |
Example 3 | Manny Nosowsky (Q6751034) → Manny+Nosowsky |
Example 4 | Bill Clinton (Q1124) → Bill+Clinton |
Source | https://www.xwordinfo.com/ConDebuts (since 1993) + https://www.xwordinfo.com/PSCons (before 1993) |
Number of IDs in source | 1222 + 874 (minus exactly 100 overlaps) = 1996 |
Formatter URL | https://www.xwordinfo.com/Thumbs?author=$1 |
Motivation Edit
Preeminent database for New York Times crossword history. I'm new to this side of Wikidata, please let me know if anything's amiss. Hameltion (talk) 01:16, 21 June 2023 (UTC)
Discussion Edit
FaroeSoccer referee ID Edit
Description | FaroeSoccer identifier for an association football (soccer) referee |
---|---|
Represents | FaroeSoccer (Q62018169) |
Data type | External identifier |
Domain | human (Q5) |
Example 1 | Sólbjørn Mortensen (Q109452034) → 976 |
Example 2 | Súni Fríði Johannesen (Q3979333) → 192 |
Example 3 | Baldvin Baldvinsson (Q109452847) → 41 |
Source | https://www.faroesoccer.com |
External links | Use in sister projects: [ar] • [de] • [en] • [es] • [fr] • [he] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt]. |
Planned use | for usage in stated in (P248) and for Template:Authority control (Q3907614) |
Expected completeness | eventually complete (Q21873974) |
Formatter URL | https://www.faroesoccer.com/referee.php?refereeID=$1 |
Robot and gadget jobs | Maybe check captures in Internet Archive for just in case? |
See also | WorldFootball.net referee ID (P6314), PlaymakerStats.com referee ID (P6315) |
Motivation Edit
Valuable statistical data, professions outside football and another bio data. IDs for FaroeSoccer player ID (P6627) are differnt. --Mitte27 (talk) 00:17, 9 August 2023 (UTC)
Moviefone person ID Edit
Description | ID of a person in Moviefone |
---|---|
Represents | Moviefone (Q6926887) |
Data type | External identifier |
Domain | human |
Allowed values | \d+ |
Example 1 | Denzel Washington (Q42101)→https://www.moviefone.com/celebrity/-/1025024/main/ |
Example 2 | Steven Hilliard Stern (Q3499236)→https://www.moviefone.com/celebrity/-/1872304/main/ |
Example 3 | Paul Comi (Q2059180)→https://www.moviefone.com/celebrity/-/1785148/main/ |
External links | Use in sister projects: [ar] • [de] • [en] • [es] • [fr] • [he] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt]. |
Formatter URL | https://www.moviefone.com/celebrity/-/$1/main/ |
Motivation Edit
One of American film websites.--GZWDer (talk) 12:23, 25 August 2023 (UTC)
Discussion Edit
- @GZWDer: I don't think you want to use the Statement template for examples like that, the links are to wikidata items. ArthurPSmith (talk) 21:16, 25 August 2023 (UTC)
Armasanicana person ID Edit
Description | identifier for a person in Armasanicana, biographical directory of the people of Aimargues since 1798 |
---|---|
Data type | External identifier |
Domain | human (Q5) |
Example 1 | Jean Jalabert (Q118435453) → jean-jalabert |
Example 2 | Henri-Noé Pagès (Q116258763) → henri-noe-pages |
Example 3 | Sully Delord (Q122617114) → sully-delord |
Formatter URL | https://armasanicana.wordpress.com/$1 |
92.184.107.241 21:35, 16 September 2023 (UTC)
Full name Edit
Philippine middle name Edit
Represents | Filipino middle name (Q7645270) |
---|---|
Data type | Item |
Example 1 | Francisco Afan Delgado (Q2793511) → Afan (Q121415846) |
Example 2 | Rolando Ramos Dizon (Q7360581) → Ramos (Q1643088) |
Example 3 | Oscar Samson Rodriguez (Q7106241) → Samson (Q18211374) |
Planned use | For Philippine citizens and diaspora with this naming scheme |
See also | Vietnamese middle name (P8500), Scandinavian middle family name (P6978), second family name in Spanish name (P1950), first family name in Portuguese name (P9139) |
Motivation Edit
In the Philippines a maternal surname is generally placed in the middle of a persons name, similar to how it is in Portuguese, right now a lot of Filipino items incorrectly use the Spanish naming scheme property where the first family name is paternal and "main" one while the second family name is maternal. Similar to the Vietnamese and Scandinavian properties I think there should be one for the traditional naming convention of the Philippines.StarTrekker (talk) 15:12, 13 August 2023 (UTC)
Discussion Edit
- Notified participants of WikiProject Names
Profession Edit
Work Edit
Salary level Edit
Description | level of someone's salary |
---|---|
Data type | Item |
Example 1 | Ronald Moultrie (Q106355213) => ES Level 3 Pay (Q116156299) |
Example 2 | Azyumardi Azra (Q4216351) => IV/e (Q116033467) Source |
Example 3 | Komaruddin Hidayat (Q6428174) => IV/e (Q116033467) Source |
Example 4 | Kay Scheller (Q16219274) => Salary grade B 11 (Q116156278) (als Präsident des Bundesrechnungshofes) |
Example 5 | Eva Högl (Q1379228) => Salary grade B 11 (Q116156278) (als Wehrbeauftragte des Deutschen Bundestages) |
Motivation Edit
In many countries government staff have salary levels, this would be nice to categorize in Wikidata Germartin1 (talk) 14:58, 5 January 2023 (UTC)
Discussion Edit
- Support --Tinker Bell ★ ♥ 00:34, 25 January 2023 (UTC)
- Comment Wouldn't it be better to link the salary grade to the itens about the staff position? e.g. Präsident des Bundesrechnungshofes --> Salary grade B 11? TiagoLubiana (talk) 12:22, 26 January 2023 (UTC)
- Yes good idea, however some positions don't have specific pay-grades or multiple ones. Germartin1 (talk) 14:52, 26 January 2023 (UTC)
- Oppose to the proposed model. Having the information for staff positions would make more sense. Otherwise, having it as a qualiifer would be better than as a main statement. ChristianKl ❪✉❫ 20:45, 26 January 2023 (UTC)
- Conditional support Having this property seems useful, but it shouldn’t be used on instances of human (Q5). Rather, its uses should be limited to
• instances of position (Q4164871) or similar (How much does anyone holding that kind of position (typically) make?), or else
• in contexts that establish the connection between those and their position-holders: either
• instances of term of office (Q524572) or similar (How much does this term entitle its appointee to?), or
• as qualifiers on statements on instances of human (Q5) with position held (P39) or similar (How much does the person make from that employment?).
―BlaueBlüte (talk) 08:51, 1 February 2023 (UTC)