Open main menu

Wikidata:Property proposal/Organization

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.

  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 2019/10.


representative in legislatureEdit

   Under discussion
Descriptionperson who represents the constituency in the legislative body
Representsmember of parliament (Q486839)
Data typeItem
Domainelectoral districts, administrative units
Example 1Electoral district #213 (Q63087844)Boryslav Bereza (Q18346435) [ legislative body (P194) = Verkhovna Rada (Q176296) ]
Example 2Islington North (Q1077552)Jeremy Corbyn (Q291169) [ legislative body (P194) = House of Commons (Q11005) ]
Example 3New York (Q1384)Kirsten Gillibrand (Q22222) and Charles Ellis Schumer (Q380900) [ legislative body (P194) = United States Senate (Q66096) ]
Example 4Sixth constituency for French residents overseas (Q1103423)Joachim Son-Forget (Q30343074) [legislative body (P194)French National Assembly (Q193582)]
Planned useTo put this property into all items about Ukrainian electoral districts, one statement per each convocation.
Robot and gadget jobsI will do the work myself
See alsoelectoral district (P768) (inverse property)


Valuable information about electoral districts, which can not be added using any other existing property. --Tohaomg (talk) 19:10, 22 June 2019 (UTC)


ChristianKl Oravrattas Tagishsimon Jacksonj04 Owenpatel Markcridge Louisecrow Nomen ad hoc Tubezlob Siwhitehouse Mhl20 Alexsdutton Danadl Teester Zache a_ka_es Hasive Nat965 masti Papuass Jklamo ProtoplasmaKid Jmmuguerza Graemebp Pete Forsyth Jelabra Rfitzel Davidpar Canley Bodhisattwa CYAN Masssly MJL tdombos salgo60 Daniel Mietchen Lefcentreright

  Notified participants of WikiProject every politician ChristianKl❫ 09:25, 25 June 2019 (UTC)

  •   Comment Tohaomg: interesting. But isn't it similar to represented by (P1875)? Nomen ad hoc (talk) 09:56, 25 June 2019 (UTC).
      Comment I think that widening scope of represented by (P1875) will be better.--Jklamo (talk) 10:01, 25 June 2019 (UTC)
    OK. Hence   Support. Nomen ad hoc (talk) 10:52, 25 June 2019 (UTC).
    Nomen ad hoc represented by (P1875) has a constraint that it is to be used in items about humans, and according to usage list it is indeed used almost exclusively in items about humans. --Tohaomg (talk) 13:05, 25 June 2019 (UTC)
      Comment Indeed; you're right. Nomen ad hoc (talk) 14:01, 25 June 2019 (UTC).
  • Is there any benefit of duplicating gazillions of statements to administrative layers (when they match electoral districts)? I think we already have too many person listings on administrative layers and should better find a way to avoid them entirely .. --- Jura 11:24, 25 June 2019 (UTC)
    Jura1, Pasleim, Yair rand, Oravrattas Currently, I am creating an infobox in ukwiki about electoral districts. There, it should be very handy just to take a value of proposed property for a field "current representative". --Tohaomg (talk) 13:11, 25 June 2019 (UTC)
    • Well, we should probably give it some thought how to improve the overall situation. Recent somewhat odd growth lead to many issues, content-wise and structure-wise, and a we should avoid adding more to that. Currently I can only offer you the inclusion of a listeria list or a sparql chart as alternatives. --- Jura 14:59, 25 June 2019 (UTC)
  •   Oppose unnecessary inverse property. Better comment on Wikidata:Property proposal/inverse label such that inverse properties can be displayed automatically. --Pasleim (talk) 11:33, 25 June 2019 (UTC)
  •   Oppose per Yair rand (talkcontribslogs) --Oravrattas (talk) 11:34, 25 June 2019 (UTC)
  •   Oppose the representation for electoral districts is subject to regular change and there is variation in exactly how representation works across legislatures. The every politician project has spent time trying to come up with standard and consistent ways of representing this, including the ability to represent past and current representation. I think the existing approaches described at Wikidata:WikiProject every politician/Political data model should be sufficient --Owenpatel (talk) 15:41, 25 June 2019 (UTC)
  • @Pasleim, Yair rand, Oravrattas, Owenpatel: In the absence of a property such as this on a constituency item, how would one obtain the most recent representative for a given constituency on that constituency's Wikipedia page (or on any other page which uses the constituency's Wikidata item)? It seems to be near impossible to do so with the current Wikibase Lua API and in the absence of progress on phab:T199887 and phab:T185313. Mahir256 (talk) 22:37, 29 June 2019 (UTC)
    • See my comment above. --- Jura 11:37, 1 July 2019 (UTC)

  • Yair rand, Pasleim, Oravrattas, Owenpatel, let me summarize it. You deprived ME of a way to improve items about Ukrainian electoral districts, because YOU failed to determine how such a property should look like in your opinion, and gave me no adequate alternative options how can I do it (apart from absurdly difficult options of listeria or sparql chart).--Tohaomg (talk) 14:54, 1 July 2019 (UTC)
    Redundant formats reduce data quality. We lose both accuracy and comprehensiveness when we split efforts across multiple properties. It is not worth it to lower the quality just to make infoboxes easier for the likely (relatively) brief period of time until development work catches up. --Yair rand (talk) 22:32, 1 July 2019 (UTC)
  •   Oppose as a redundant inverse of an existing property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:28, 22 September 2019 (UTC)

debated byEdit


Debating on a motion before an assembly is the most important step to propose something . This property will help create data about the seconders debaters who have participated in any parliamentary democracy. The more we can create data about motions and politicians who have actively participated in parliamentary democracy, a simple query will reflect how well an elected member engaged in the assembly. Bodhisattwa (talk) 15:22, 26 April 2019 (UTC)


ChristianKl Oravrattas Tagishsimon Jacksonj04 Owenpatel Markcridge Louisecrow Nomen ad hoc Tubezlob Siwhitehouse Mhl20 Alexsdutton Danadl Teester Zache a_ka_es Hasive Nat965 masti Papuass Jklamo ProtoplasmaKid Jmmuguerza Graemebp Pete Forsyth Jelabra Rfitzel Davidpar Canley Bodhisattwa CYAN Masssly MJL tdombos salgo60 Daniel Mietchen Lefcentreright

  Notified participants of WikiProject every politician Bodhisattwa (talk) 20:55, 26 April 2019 (UTC)

  •   Support Seems useful. Nomen ad hoc (talk) 21:03, 26 April 2019 (UTC).
  •   Support This would be a very good edition to our coverage of legislation (Q49371). –MJLTalk 03:39, 27 April 2019 (UTC)
  •   Oppose I have a few different issues with this, as currently proposed. Firstly, though only minor, the "motivation" section seems to have been accidentally swapped with seconded by. More significantly, the examples given seem to conflate the outcome of a debate with the debate itself, and having something like Aims and Objectives Resolution of the Constituent Assembly of India (Q63343205) be both a "constitutional document" and a "motion" is likely to cause significant issues further down the line. It's certainly worth being able to record these things, but we need more thought as to the best way to do so. In most legislative systems there isn't as clean a 1:1 mapping between outcomes (e.g passed laws) and the various debates and motions that lead to them. We would also need to be careful not to end up with a solution that only works for a single type of legislative procedure. My suspicion is that if we were to have an item for any important debate itself (separate from the outcome of the debate), we could usefully use participant (P710) instead, with qualifiers to specify how the person participated (e.g. proposing or seconding a motion, giving an important speech, casting a certain vote etc), with much more flexibility that needing new properties for each of these. That also seems like it would be simpler to query for many of the common requirements. --Oravrattas (talk) 05:31, 27 April 2019 (UTC)
  •   Support David (talk) 05:33, 27 April 2019 (UTC)
  •   SupportHrishikes (talk) 04:04, 28 April 2019 (UTC)
  •   Wait This property would need a good definition that species what it means. Does debating only refers to saying things in an full session of a parliament? Do committees count? Do debates outside of the parliament count? ChristianKl❫ 18:50, 5 May 2019 (UTC)
  •   Oppose would this list every member of an assembly? The assembly itself? It doesn't seem needed --DannyS712 (talk) 20:07, 23 May 2019 (UTC)
  •   Oppose. Needs further clarification, per above. --Yair rand (talk) 21:06, 2 July 2019 (UTC) politician identifierEdit

   Under discussion (the official site of the Danish parliament) has an identifier string in the URL's of biographies of politicians. Politician's items can use this property and e.g. Wikipedia can automatically link the official biography on
Data typeString
Domainmember of the Folketing (Q12311817)
Allowed values[a-z-]+ (note that the a-z should include Danish and Færøer characters)
Example 1Carolina Magdalene Maier (Q20197678)carolina-magdalene-maier
Example 2Per Stig Møller (Q697184)per-stig-møller
Example 3Sjúrður Skaale (Q845278)sjúrður-skaale
Planned useautomatically generate links from English and Danish Wikipedia articles of politicians
Number of IDs in sourceat least 179 current members of Folketing, probably double for all former members of the last decade
Expected completenessalways incomplete (Q21873886)
Robot and gadget jobsYes, should validate that the implied URL is not a 404.
See alsoProperty:P6849


Currently, Danish and English (and presumably other) Wikipedias manually link the politicians official biography. All recent politicians have profile pages like this, the Parliament management writes the biography. By having a property, it would be easier to change the URL prefix, it would be easier to update values across Wikipedias, the value could be automatically used from e.g. da:Template:Infoboks MF. That infobox already shows official URL's, but they are freeform and some politicians have the official bio in there, some do not (for arbitrary reasons). By using this property, information would be organized in a stricter schema. Note that politicians that retired long ago do not have current biographies (their bio's have different URL schemes). This proposal does not concern those politicians.

The different classes of biographies on are (as far as I can see):

newish (note that she also has a bio with the current schema . Her item would have this property with value "merete-dea-larsen")
old (note that she does not have a bio with the current schema or the other old schema. Her item would not use this property, manual linking would continue)
new (note that she ONLY has a biography with the newest schema. This search with the foreign URL scheme yields no results: [1]. Her item would have this property with value "aki-matilda-hoeegh-dam")

There are also PDF versions, sometimes in English, but I don't think we should link those, they offer no inherent advantage over HTML.

If any biography page on loads with no text, set the language to Danish by prepending "/da" to the path portion of the URL.

Note that the part before the last / in the URL is just the first letter of the name. For example, Carolina has a "c" in the URL as seen above. This character can be extracted from the property value by Mediawiki string manipulation functions using Scribunto.

I would set the "formatter URL" to{{Module:String|sub|s=$1|j=2}}/$1 but the proposal template doesn't accept my syntax with template invocations and nowiki tags.

To see examples of pages that currently have manually inserted external links, and which would be able to use a template extracting data from this property see:

Ysangkok (talk) 18:32, 6 July 2019 (UTC)


Is there any way to combine the two versions in the same property? The identifiers can be extracted from each other, but the rules for that cannot be expressed in the formatters as far as I know. --Dipsacus fullonum (talk) 21:26, 7 July 2019 (UTC)
Oh, didn't realize it was so simple. I propose we just only save the part after the slash, e.g. "carolina-magdalene-maier". Templates can use Lua to take the first character, and generate the Danish bio link programmatically. It can easily be done using e.g. w:Module:String. I am not sure why you are doubting this, since you know about how templates work. As previously mentioned, it would be Wikipedia templates actually generating the links, Wikidata just needs the property so that we'd be able handle the eventual case of a politician where the ID on doesn't match the name we store. Actually, we'd probably be able to generate 99% of the links by just taking all names, concatenate them with "-" in between, and prepend the prefix (with the Danish link having the extra duplicated first character). But I would prefer to have this property, since it would be fragile without it. --Ysangkok (talk) 17:48, 8 July 2019 (UTC)
  •   Support--Trade (talk) 22:53, 31 August 2019 (UTC)

nominal share capitalEdit

   Under discussion
Descriptiontotal of the nominal values of the issued ordinary and preference shares of the entity
Representsshare capital (Q330601)
Data typeQuantity
Domainorganization (Q43229)
Allowed valuesNumbers
Allowed unitsInstances of currency (Q8142)
Example 1Bourbon Corporation (Q2922257) → 49189434 euro (Q4916)
Example 2Électricité de France (Q274591) → 1525484813 euro (Q4916)
Example 3Telefónica (Q160229) → 5192131686 euro (Q4916)
See alsomarket capitalization (P2226)


I guess this would be quite useful for items about companies. Thierry Caro (talk) 12:45, 13 October 2019 (UTC)


Kopiersperre Jklamo ArthurPSmith S.K. Givegivetake fnielsen rjlabs ChristianKl Vladimir Alexiev User:Pintoch Parikan User:Cardinha00 User:zuphilip MB-one User:Simonmarch User:Jneubert Mathieudu68 User:Kippelboy User:Datawiki30 User:PKM User:RollTide882071 Kristbaum Andber08 Sidpark SilentSpike Susanna Ånäs (Susannaanas)

  Notified participants of WikiProject Companies. Thierry Caro (talk) 12:45, 13 October 2019 (UTC)

  •   Neutral Not sure whether this is a particularly interesting number. I suppose it lets one calculate how much a block of N shares each of nominal value X represents out of the total stock of a company (though that calculation may not be straightforward, or even possible without additional information, if there are different classes of shares). Defer to members of WikiProject Companies as to whether this is actually a useful thing to bother with. Our current infoboxes for companies on en- and fr-wiki don't appear to include it.Jheald (talk) 01:46, 14 October 2019 (UTC)
  •   Comment It may be useful, but please consider to clean-up share capital (Q330601) vs Q125104 (I think they are covering at least 3 concepts). Then specify, to which concept is proposal related - joint-stock company (Q134161) or more general. At cswiki we already have parameter "Základní kapitál".--Jklamo (talk) 03:07, 14 October 2019 (UTC)
  •   Support David (talk) 16:42, 14 October 2019 (UTC)


See also Wikidata:Property proposal/Pending for approved items awaiting the deployment of currently unavailable datatypes

unit sizeEdit

   Under discussion
Descriptionsize classification of military unit
Representsmilitary unit size class (Q21506450)
Data typeItem
Allowed valuesQ21506450
Example 11st Armored Division (Q163673) military unit size division (Q169534)
Example 2signals regiment (Q47423740) military unit size regiment (Q52371)
Example 3infantry squad (Q47250366) military unit size squad (Q207063)
Example 4Filo (Q62649248) military unit size squadron (Q679165)


Permit connecting a military unit to the item related to its size. Josh Baumgartner (talk) 04:20, 11 April 2019 (UTC)


  •   Support David (talk) 08:31, 11 April 2019 (UTC)
  • From the examples, it appears that this would be used for both classes of units and individual units. For the latter, wouldn't this be redundant with P31? Or would the P31 value be changed to something else? --Yair rand (talk) 20:35, 11 April 2019 (UTC)
    I am not sure exactly how Wikidata is handling these kinds of redundancies these days...whether instances inherit the properties of their class or if they are separately attached. As far as I have seen, there is not consistency. I am fine with actual implementation of the property matching whatever the prevailing method is, my point is only to bring it into existence so we can start attaching this information. Josh Baumgartner (talk) 02:21, 12 April 2019 (UTC)
  •   Oppose Redundant with instance of (P31). /ℇsquilo 06:53, 16 April 2019 (UTC)
  •   Support Arpyia (talk) 08:36, 11 May 2019 (UTC)
  •   Oppose It seems to me that instance of (P31)/subclass of (P279) is already enough to express the information currently. ChristianKl❫ 08:21, 8 June 2019 (UTC)
    • @ChristianKl: Your sentiment matches mine for a long time, but here is what I am struggling with, so perhaps you can help me out here: Nearly all non-identifier properties could be replaced with instance of (P31)/subclass of (P279), and I often see the argument made that a property should be deleted or not created because the information can be expressed already with P31/P279. And this is true, it can. But yet there is no policy that if it can be done at all with an existing property, that a new property can't be used, even if it offers an advantage. The fact is that while P31/P279 can express the literal connection between items, they are not good at providing context and they are difficult to reference correctly, as outside sources are not likely to tailor their descriptions and definitions to the structure of Wikidata classification. Distinct properties allow users, both machine and human, to more quickly access the data they seek. Using P31/P279 for example, a reader seeking the size of a unit would have to query each value of P31/P279 to ask it 'are you a size classification?', and this would potentially need to be done through several levels depending on how deep of a classification exists for the item. It would be an especially difficult problem to identify those items for which a link to a unit size classification has not been added yet (how recursively do you query the database until you give up?). On the other hand, a distinct property for 'unit size' would allow that information to be accessed directly from the item's page with no need for recursive queries, and both machine (by seeking the exact property) and humans (by reading the property label) would immediately be able to identify the desired information with a minimum of workload for both the user and the database. So a pretty simple example: Seeking the answer to this question, "What is the unit size of 223rd Squadron (Q62783320)?" If it has the statement 223rd Squadron (Q62783320) unit size squadron (Q679165) then a simple query 'return the value of P# (unit size) for Q62783320' is all that is needed. How complex would the query need to be if we only have P31/P279? Josh Baumgartner (talk) 03:40, 26 July 2019 (UTC)
  • @ChristianKl: But not several others (i.e. organization (Q43229)). I'm sorry, but instance of (P31) does not permit a controlled way to add a sourced claim without relying on several other tenuous uncontrolled links. A defined property remains the more elegant and direct solution to the requirement. Josh Baumgartner (talk) 16:30, 20 September 2019 (UTC)

IP range startEdit

   Under discussion
Descriptionstart of the IP range in hexidecimal
Data typeString
DomainQualifier for IPv4 routing prefix (P3761) and IPv6 routing prefix (P3793) in raw hex.
Allowed values^[0-9a-f]{8,12}$
Example 1University of Oxford (Q34433)IPv6 routing prefix (P3793) → 2001:630:440::/44 → 20010db81234
Example 2Wikimedia Foundation (Q180)IPv4 routing prefix (P3761) → → c6231a00
Example 3Johns Hopkins University (Q193727)IPv4 routing prefix (P3761) → → 80dc0000
Example 4University of Chicago (Q131252)IPv6 routing prefix (P3793) → 2a03:b600:640::/107 → 2a03b6000640
Planned useCreate a bot to update the qualifier based on the values in the properties.
Robot and gadget jobsThis qualifier should be populated with a bot that I will write
See alsoIPv6 routing prefix (P3793) & IPv4 routing prefix (P3761)


I would like to make a tool in toolforge that will allow a user to input an IP address and get the organization (Q43229) associated for that IP address. Unfortunately, you cannot query a range unless you have the start and end of that range. Therefore, I would like to create this property (and I will propose an end range if this is approved) that will be populated by a bot. Then organizations can be queried by the IP address. I chose raw hex as a format because that is what MediaWiki uses in the ipblocks table, however any ordered format should work (for instance, a non-seperated decimal format, etc.) U+1F360 (talk) 14:51, 26 September 2019 (UTC)


  •   Comment This would be redundant with the IP range itself. To make such a tool, the simplest way is to do as follows: 1. extract all the IP ranges know to Wikidata with SPARQL, 2. index them in your own database, with the appropriate datatype (for instance postgresql has a dedicated datatype for ranges, but it can also be done with numeric fields in MySQL / MariaDB), 3. Query your SQL database directly. (4. set-up a job to periodically update your database from Wikidata). − Pintoch (talk) 15:04, 26 September 2019 (UTC)
    • That is true, that is a way to do it, but is it valuable for other people to be able to query the data themselves? I suppose ideally there would be a new type of field that would allow for more than one value (start and end), but as far as I know that doesn't exist right now. U+1F360 (talk) 15:09, 26 September 2019 (UTC)
    • Another way to (maybe) solve this, would be to create a FILTER in SPARQL, but I'm not sure that's possible (errr... if it can create a FILTER that would index that itself rather than having to generate the range for every item on every query). U+1F360 (talk) 15:19, 26 September 2019 (UTC)
    • I'm asking the development team if there is a better solution than duplicating the data Wikidata:Contact_the_development_team#IP_Range_Querieis. U+1F360 (talk) 15:51, 26 September 2019 (UTC)
@U+1F360: Well, almost any solution is going to require duplication somewhere… you’re proposing to duplicate the data in the qualifiers, Pintoch is suggesting to duplicate it in an external database instead, and special support in Wikibase/WDQS would most likely require duplication in some internal index. I don’t think adding special support for this to the query service is worth the effort, so I agree with Pintoch that an external database seems like the preferable approach. (You can also make that database accessible to other tools, e. g. via a simple HTTP API, to avoid them having to repeat the work.) --Lucas Werkmeister (WMDE) (talk) 12:05, 30 September 2019 (UTC)
  •   Oppose. If attempting to represent an IPv4 or IPv6 range with a Quantity data type rather than String data type (due to the extra complexity in parsing String data types), then the value should be in decimal (base 10) notation with the value selected as the middle of the range, with +/- X where X is the distance to the start and end of the range. Dhx1 (talk) 14:02, 8 October 2019 (UTC)
    • @Dhx1: That is a great idea! Let me figure out some examples. U+1F360 (talk) 14:06, 8 October 2019 (UTC)
    • @Dhx1: As a worse case scenario example, if the range was then the value would be 167772287±127.5 167772287.5±127.5? That seems awesome to me (rounding up in either direction gets the most extreme values). Since that value can be queried, and the current CIDR cannot be, perhaps this should be the default and the existing field should be deprecated? If someone needs the CIDR syntax it's a simple conversion to get the start and end and convert that CIDR (I'm just wondering if it would be wise to not duplicate the data per the discussion above). U+1F360 (talk) 20:30, 8 October 2019 (UTC)
    • @Dhx1: Oops. I did my math wrong, given the value would be 167772287.5±127.5. Even better, doesn't require rounding to get the start and end of the range. U+1F360 (talk) 21:23, 8 October 2019 (UTC)
    • Here's the remaining questions I have:
  1. Should I create a new proposal and close this one, or modify/rename this one?
  2. Should this be a new main property (i.e. not a qualifier)?
  3. Should the existing properties be deprecated?
  4. Should there be a property for IPv4 and IPv6? Or should there be a single property and require a of (P642) qualifier with Internet Protocol version 4 (Q11103) or IPv6 (Q2551624) values? Or should we use the Unit with IP address (Q11135) or IPv6 address (Q11097)? U+1F360 (talk) 01:15, 9 October 2019 (UTC)
  •   Comment Upon further thought, I think it would be best if a new data type was created that extends from quantity. This would be similar to the way Commons Media extends from string. Doing this would allow the user to input (and display) an IP address, or a CIDR range, and that data would be stored in deceimal format (see above). Likewise, it would allow that data to be queried by converting an IP address to decimal format. @Lucas Werkmeister (WMDE): if I were to write a patch for this, would WMDE be willing to review and merge it? U+1F360 (talk) 15:59, 10 October 2019 (UTC)
    • @U+1F360: I   Support having a new datatype for this; there is a phabricator "epic" phab:T91505 for tracking proposals for new datatypes, and you can see how some of those have faired over the past few years. ArthurPSmith (talk) 16:49, 10 October 2019 (UTC)
    • I created a new task phab:T235389. I think this proposal can be closed and I'll create a new one once that work is done. :) U+1F360 (talk) 16:43, 13 October 2019 (UTC)