Shortcuts: WD:PP/GEN, WD:PP/Generic

Wikidata:Property proposal/Generic

From Wikidata
Jump to: navigation, search

Property proposal: Generic Authority control Person Organization
Event Creative work Term Space
Place Sister projects
Economics Transportation Natural science Property metadata

See also:
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.

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 (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. Change status=ready on template to attract the attention of a property creator.
  2. Creation can be done after 1 week by a property creator or an administrator.
  3. See steps when creating properties.

This page is archived, currently at Archive 53.

Property proposal: Generic Authority control Person Organization
Event Creative work Term Space
Place Sister projects
Economics Transportation Natural science Property metadata

Generic properties[edit]

permanent duplicated item[edit]

   Under discussion
Description – (Please translate this into English.)
Data type Item
Allowed values instances of Wikimedia permanent duplicated page (Q21286738) or item linked with this property from an item with instances of Wikimedia permanent duplicated page (Q21286738)
Example universe (Q1)no label (Q22924128), no label (Q22924128)universe (Q1)

Currently, items are using said to be the same as (P460) for linking to items linked to duplicate articles with different scripts. This should be split into a separate property to avoid confusion. --Yair rand (talk) 13:39, 29 March 2016 (UTC)

Symbol support vote.svg Support shouldn't this be "duplicate of item", "duplicate of" or something like that? - Brya (talk) 11:21, 30 March 2016 (UTC)
@Brya: Not "duplicate of", I think. This property is "meta", referring to Wikidata items themselves, so it needs to be distinguished. (Duplicate items are only necessary in the first place because of Wikibase limitations.) "duplicate of item" means the same thing as "duplicate item", since it's a symmetrical relation, so I don't think it makes a difference which is used. --Yair rand (talk) 21:27, 30 March 2016 (UTC)
Very often (always?) the relationship is not symmetrical: on the one hand there is the full item (with all the trimmings), while on the other hand there is the duplicate which holds just one sitelink (to a page that should be cleared/merged/redirected as soon as possible). - Brya (talk) 04:49, 31 March 2016 (UTC)
From the proposal, this doesn't seem to apply to items that should be merged/redirected.
--- Jura 06:15, 1 April 2016 (UTC)
I see. OK. - Brya (talk) 10:38, 1 April 2016 (UTC)
  • Pictogram voting comment.svg Comment Could you add "permanent" to the label? Otherwise people use it for items that are just waiting to be merged.
    --- Jura 04:08, 31 March 2016 (UTC)
  • Pictogram voting comment.svg Comment There is another problem. For some wikis, it's easy to figure out that there are two items about the same topic in different scripts, but it's not necessarily clear which one is the duplicate (this can depend on choices at that wiki). For these it's easy to add P460, but the next steps are more complicated. If a new property being used, this makes sorting them out much more complicated, unless it's symmetrical as well.
    --- Jura 04:14, 31 March 2016 (UTC)
    On nnwiki is it rather straightforward. The main script of the wiki is Nynorsk (nn). The duplicate articles are in Högnorsk, a third unofficial way to write Norwegian. If we ever will have a Högnorsk wiki, those articles will most likely be transferred to that wiki. In that way these articles are maybe not "permanent duplicates". But it m8 take decades before there is a Högnorsk wiki if ever. A little to big part of the Nynorsk articles are just copy-pasted Bokmål-articles (nb) that has not been translated yet. -- Innocent bystander (talk) 07:51, 31 March 2016 (UTC)
    I can't really say how it works at hywiki, just that they do have two and P460 links them. When I added them, I think quite a few items didn't have any statements at all. BTW, I think the templates to get additional interwikis work with P460. If we remove them, we would need to find another way.
    --- Jura 06:15, 1 April 2016 (UTC)
  • Pictogram voting comment.svg Comment I think this property label would be confusing and abused (as Jura seems concerned about) - what about something more specific: 'item referenced in alternate script' maybe? Is there any prospect of wikibase handling this sort of case better? ArthurPSmith (talk) 19:41, 1 April 2016 (UTC)
    • The bulk on Wikidata:Database_reports/permanent_duplicates are articles in different languages (or dialects depending on the POV). The second item is really about the same as the first one. So "same as" isn't incorrect. It can be a different script, but it needn't. Maybe a symmetrically used "same as (WikiMedia permanent duplicates)" would do?
      --- Jura 17:27, 3 April 2016 (UTC)
      • I updated it accordingly.
        --- Jura 15:34, 6 April 2016 (UTC)
        • @Jura1: Hm, I'm not really in favor. I like making a firm distinction between the Wikidata page/item and the topic represented. Titling the property "same as", with extra disambiguating content, is misleading. There isn't topic X which is same as topic Y. The Wikidata item has, for technical purposes, an associated item here. The extra item has no topic, it's just a technical unit. --Yair rand (talk) 23:01, 11 April 2016 (UTC)
          • Tricky. What solution do you suggest for the hywiki usecase presented above? Do you have some you came across and added statements? Maybe "items with sitelinks about the same".
            --- Jura 09:51, 15 April 2016 (UTC)
            • For hywiki alternate script pages, only one of the two pages should be linked to the item that functions as the item for that topic. In my opinion, permanent duplicated items should have no statements beyond those identifying its status as a duplicated item of something else. "Same as" would be something we'd use for "real" items (ie, those with topics). --Yair rand (talk) 22:45, 1 May 2016 (UTC)
              • The question is not what item should get what, but if items don't have any other statements, personally, I can only determine that they are the same, but not which one should get what. Thus the advantage of a symmetric property. BTW, I don't think they are alternate script pages.
                --- Jura 07:27, 5 May 2016 (UTC)
  • Symbol support vote.svg Support, although I would prefer a more specific name, possibly refering to Wikimedia projects. Of course, ideally I would prefer the ability to have multiple sitelinks to the same projects, as also required for Commons. --Srittau (talk) 20:05, 11 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose I am not happy with the one-sitelink-per-project-and-item rule but adding this property would break a basic assumption of Wikidata data model. The problem could also be resolved in each single Wikipedia or file a bug report on Wikibase software. Could you give some more examples where it is actually needed? -- JakobVoss (talk) 12:27, 12 June 2016 (UTC)
    @JakobVoss: Which basic assumption is that (which would be broken)? Further examples: Brussels (Q239) => no label (Q13054517), no label (Q16634496) => Slavic studies (Q156864), Estoniä (Q17363906) => Estonia (Q191). These are currently using said to be the same as (P460), which has the unfortunate side effect of bringing the technical-necessity items into the scope of things-that-exist items, which has substantial potential for confusion and broken Wikidata queries. --Yair rand (talk) 22:53, 19 June 2016 (UTC)
    The assumption is to have one Wikidata item for each distinct conceptual entity. Otherwise there is no need to agree on statements and to work together. If tow items are same, they should be merged. If merging is not possible for technical reasons, like the examples above, file a bug report of feature request to Wikibase software. If merging is not possible for conceptual reasons, the items are not the same but only said-to-be the same (said to be the same as (P460)) -- JakobVoss (talk) 04:36, 20 June 2016 (UTC)
    I agree with you in principle. The current one-sitelink-per-item rule has not worked out and needs to be changed. This has been the source of all the woes with Commons integration as well. Unfortunately, the development team seems to have other priorities, even though I personally consider this a high-impact limitation as can be seen in this and other discussions. That said, I consider this proposal an appropriate stop-go measure. --Srittau (talk) 06:45, 20 June 2016 (UTC)
    For reference, I brought it up again here. --Srittau (talk) 06:58, 20 June 2016 (UTC)
    Whether we add this property or not, the duplicate items will continue to exist for the foreseeable future because it's not possible to merge them. If we later get support for multiple sitelinks on an item, we can use this property to find items which need merging and then delete the property. - Nikki (talk) 11:51, 20 June 2016 (UTC)
  • Symbol support vote.svg Support I think a dedicated property is a good idea. There's no obvious way to mark things as duplicates so people use various inconsistent methods. I think the label should start with "Wikidata" though so that it's more consistent with the other Wikimedia/Wikidata/etc properties/items. - Nikki (talk) 11:51, 20 June 2016 (UTC)
  • Symbol support vote.svg Support I'm in favor, too. An advantage to having a property like this could also be that something might then be rigged up wherein the "permanent duplicate" is automatically fed the interwiki links of its twin all all languages not also having duplicates.
    For the record, on Ladino Wikipedia, the convention we are using is that the lad-latn version is always linked, while the lad-hebr version is by itself (or in some cases, especially template or project space pages, linked to other multiple version items). On the lad-hebr pages we use Module:Interwiki (Q20819069) to feed the interwikis from the lad-latn pages to the lad-hebr page. StevenJ81 (talk) 15:43, 20 June 2016 (UTC)

disjoint with[edit]

   Under discussion
Description disjoint with
Data type Item
Domain any class
Allowed values only classes, not individuals
Example time interval (Q186081)position (Q23008351)

There is a property "different from" (P1889) which is defined as equivalent to owl:differentFrom. According to OWL, "different from" should only be used for individuals, not for classes. owl:disjointWith should be used to assert that no member of a class can be a member of the disjoint class. This is useful for reasoning in property path queries. Chjohnson39 (talk) 12:16, 5 May 2016 (UTC)

  • Pictogram voting comment.svg Comment Any example where Disjoint union of search would not fit ? author  TomT0m / talk page 12:26, 5 May 2016 (UTC)
  • Symbol support vote.svg Support --Emitraka (talk) 21:31, 31 May 2016 (UTC)
  • Symbol support vote.svg Support This is a property I might use. Definitely makes sense.--Andrawaag (talk) 21:31, 31 May 2016 (UTC)
  • Symbol support vote.svg Support Egon Willighagen (talk) 17:49, 2 June 2016 (UTC)
  • Pictogram voting comment.svg Comment There is extensive discussion regarding "disjoint with". --Izno (talk) 12:30, 3 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose, per TomT0m. If this intends to replace disjoint union of (P2738), we need to have a discussion about that first. If not, then it would just be redundant, unless someone can think of a counter-example. --Yair rand (talk) 11:18, 6 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose per Yair rand, until the question by him and TomT0m have been addressed. --Srittau (talk) 20:09, 11 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose per TomT0m --Pasleim (talk) 14:54, 24 June 2016 (UTC)

Onion URL[edit]

   Under discussion
Description .onion URL for this website
Represents Tor Hidden Service (Q19778981)
Data type URL
Domain websites
Allowed values alphanumeric
Example Facebook (Q355)https://facebookcorewwwi.onion/
DuckDuckGo (Q12805)http://3g2upl4pq6kufc4m.onion
Source List of Tor hidden services

This should make it easier to find Tor hidden services on the web. Seems like a no-brainer to have it on Wikidata. NMaia (talk) 23:45, 14 May 2016 (UTC)


Pictogram voting comment.svg Comment: this property will need to be carefully watched due to previous attempts at phishing at Wikipedia. NMaia (talk) 18:24, 29 May 2016 (UTC)

  • Pictogram voting question.svg Question Is there a reason .onion URLs need a specific property and can't just be added using official website (P856)/URL (P2699)? Thryduulf (talk: local | en.wp | en.wikt) 23:17, 29 May 2016 (UTC)
    • I'm not sure onion URLs can be machine-sorted easily from other kinds of URLs. Besides, Tor hidden services have enough structured data in themselves to warrant their own property. NMaia (talk) 13:13, 2 June 2016 (UTC)
      • Don't they all have a ".onion" TLD--of course they can be easily machine sorted. :D --Izno (talk) 12:36, 3 June 2016 (UTC)
  • Pictogram voting comment.svg Comment Given the nature of some websites on TOR, I think it would be best if we have this property (and per my question I'm unsure still if we should) that it must be accompanied by a publicly verifiable source where the .onion URI can be verified. It would look (and potentially be) very bad for Wikidata if we associated e.g. a living person with an onion URI leading to e.g. illegal pornographic material. Thryduulf (talk: local | en.wp | en.wikt) 23:17, 29 May 2016 (UTC)
    Maybe there should be a new kind of constraint "required reference"? --Izno (talk) 12:36, 3 June 2016 (UTC)
    @Izno: I can certainly see that being of benefit in several areas, particularly if the software can enforce it at the time of entry. Thryduulf (talk: local | en.wp | en.wikt) 15:59, 3 June 2016 (UTC)
    The software will never "enforce"... it will, at some point in the indeterminate future, "not-so-gently indicate that you haven't done what's necessary". I'm not sure "this must be present" is even an accounted-for case in the Wikibase Quality extension--probably not, since I doubt there's a sensible UI for something like that. --Izno (talk) 16:07, 3 June 2016 (UTC)
  • I would support this generally. --Izno (talk) 12:36, 3 June 2016 (UTC)
  • BA candidate.svg Weak oppose for now. I would like to see URL (P2699) used with a qualifier for now. If this gains enough traction, I would Symbol support vote.svg Support this property. --Srittau (talk) 20:28, 11 June 2016 (UTC)


   Not done
Description definition of a term, its meaning
Represents definition (Q101072)
Data type Monolingual text
Domain any item
Example DiGeorge syndrome: A T cell deficiency disease that is the result of a large deletion of chromosome 22 which includes the DGS gene needed for development of the thymus and related glands with subsequent lack of T-cell production.
Robot and gadget jobs ProteinBoxBot might use this property to add textual definitions to diseases and other items it updates.

A textual definition of any given item/term is standard practice in the world of ontologies, and in almost everything else. A quick statement about the meaning of a thing. The "official" definition of 'definition' from the Information Artifact Ontology: "The official OBI definition, explaining the meaning of a class or property. Shall be Aristotelian, formalized and normalized. Can be augmented with colloquial definitions." It should not be constrained by that, but it is a good guideline, at least. Regarding the 400 character limit, if it does go above that then we should truncate and the interested party can follow the reference. Emitraka (talk) 21:28, 31 May 2016 (UTC)

  • Symbol support vote.svg Support --Andrawaag (talk) 22:09, 31 May 2016 (UTC)
  • Symbol oppose vote.svg Oppose Use the description--this is what that is there for to some extent. --Izno (talk) 11:41, 1 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose per Izno. This is also a multilingual project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:31, 2 June 2016 (UTC)
  • Pictogram voting comment.svg Comment if this is implemented it should be as monolingual text rather than string (per Andy's comment about this being a multilingual project). Unless you (Andrawaag or anyone else) can explain how this is different to the description though I'm inclined to oppose per Izno. Thryduulf (talk: local | en.wp | en.wikt) 12:43, 2 June 2016 (UTC)
    @Izno: @Thryduulf: The main problem with the description is that you cannot use qualifiers nor references to add provenance to that description. Also, we can only add 1 description per Wikidata item and multiple definitions for the same concepts do exist. A quick search on the term "disease" in google two definitions; (1) "A disease is a particular abnormal condition, a disorder of a structure or function, that affects part or all of an organism" (source: or (2) "a problem that a person, group, organization, or society has and cannot stop" or "an illness that affects a person, animal, or plant : a condition that prevents the body or mind from working normally" (source: merriam-webster, etc. Also definitions can change over time. The definition of the meter being the nicest example. Historically, there are many definitions of the metre, (the wikipedia entry on the matter. I would love to be able to store those definitions using qualifiers and references to indicate when the historic ones were applicable. --Andrawaag (talk) 18:43, 2 June 2016 (UTC)
    @Izno: @Thryduulf: Just to make it clear. I agree with Andrawaag and would like to add that it can be changed to monolingual text in the proposal. (Can I do that right away? Or is it frowned upon to change anything in a proposal?) --Emitraka (talk) 18:52, 2 June 2016 (UTC)
    ✓ Done Changed the type. --Srittau (talk) 20:37, 11 June 2016 (UTC)
  • I'm going to add a bit: if you want strict relations established between items a/b, then that is probably more in the bucket of the WD:Wiktionary-Wikidata integration bucket. --Izno (talk) 15:22, 2 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose. This is not structured data. --Yair rand (talk) 17:05, 2 June 2016 (UTC)
    @Yair rand: To some extent a definition property is not that different from a accepted property like GND ID (P227) --Andrawaag (talk) 18:44, 2 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose I am not convinced that Wikidata is the right place for longer, sourced definitions. A short definition is already included in every item, but that is under out control and does not need to be referenced or qualified. Longer, external definitions are out-of-scope and also a potentially licensing hazard. --Srittau (talk) 20:39, 11 June 2016 (UTC)

 Not done No support. Lymantria (talk) 17:24, 19 June 2016 (UTC)


Description ranking in a sequential order (parent property of ranking (P1352))
Represents ordinal number (Q923933)
Data type Number
Domain all
Allowed values integers
Allowed units dimensionless quantity (Q126818)

Currently we are missing a good way to indicate the rank of an item in some sequential order. ranking (P1352) comes closest and should in my opinion become a subproperty of this one. Lymantria (talk) 17:19, 19 June 2016 (UTC)

  • Pictogram voting question.svg Question How does this differ from series ordinal (P1545) which seems to be defined as everything which has an order but which is not a ranking (ranking (P1352)). Thryduulf (talk) 23:21, 19 June 2016 (UTC)
    • Different datatype. Lymantria (talk) 08:05, 20 June 2016 (UTC)
      • Are there any examples of series ordinal (P1545) using anything other than an ordinal number as the value (none of the 20 items I clicked at random do)? If so, maybe we should just change the datatype on that? I don't understand why we need two properties for what is seemingly the same concept. Thryduulf (talk) 09:53, 20 June 2016 (UTC)
  • There has been some discussion on what datatype should be used, but "2a" should be possible. Still I think you are right, that this one is not really needed apart from series ordinal (P1545). Withdrawn. Lymantria (talk) 10:38, 20 June 2016 (UTC)


   Under discussion
Description – (Please translate this into English.)
Data type Item
Domain instance of world problem (Q24736622)
Example Homelessness → Sleeping in public places, Denial of right to private home life
Robot and gadget jobs Possibly

Hacking on importing EWPHP data into Wikidata at Wikimania with sj. Going to skip the 7 day waiting period so we can work on modeling the data in a smaller environment before doing a large thing.  – The preceding unsigned comment was added by Legoktm (talk • contribs).

  • Huh? Please provide a detailed description of the property. And additionally, no skipping. We just had a mess of a discussion regarding cites. --Izno (talk) 17:49, 23 June 2016 (UTC)
    And additionally, an example. Please be more thorough, in general. --Izno (talk) 17:50, 23 June 2016 (UTC)
    The EWPHP is a reference work with >30,000 concepts ('problems'), each of which has a list of other problems that are aggravated (amplified, intensified) by that problem. For instance, homelessness aggravates: Dependence, Vulnerability in emergencies, Excreting in public places, Underprivileged home environment, Denial of right to private home life, Humiliation, Officially nonexistent people, Contempt, and Shortage of public space for relaxation.
    The reference then uses this to, among other things, identify short cycles of conditions that aggravate one another. Sj (talk) 21:58, 23 June 2016 (UTC)
    We can more neutrally phrase this as "positively reinforces" and "negatively reinforces" or possibly "positively forces"/"negatively forces" and uses this outside this domain, I think. But it's probably a good thing overall, as long as we have references. Systems theory gets into that some. --Izno (talk) 01:22, 24 June 2016 (UTC)
    Yes, definitely systems-theory related. The founders of that encyclopedia drew from that literature in other areas as well. What does "negatively forces" mean? I like the idea of positively reinforces and negatively reinforces as properties, that does seem widely useful. Sj (talk) 12:28, 24 June 2016 (UTC)
    A negative forcing function is one which dampens the effect of the item being forced. So, same concept as negative reinforcement, just couldn't make the words come out. In general, I think the initial idea is sound and we just need some expertise with specific vocabulary. --Izno (talk) 13:30, 24 June 2016 (UTC)
Can you provide an example using existing Wikidata items? --Pasleim (talk) 14:57, 24 June 2016 (UTC)
Roughly: "homelessness (Q131327) aggravates unemployment (Q41171)". But really it would be sharper to say "homelessness (Q131327) aggravates the difficulty of finding work" (where "difficulty of finding work" is a slightly different concept than unemployment) Sj (talk) 13:20, 25 June 2016 (UTC)
Pictogram voting comment.svg Comment I think this ought to start with a property for the EWPHP id (if there is such a thing) to link existing or newly created wikidata items to EWPHP. Then propose to add any relationship properties that may be needed. Generally I would think an effort like this should have a wikiproject for it to review existing items and properties comparing with the data proposed to be imported. This might work well with Mix and Match or you may need up a bot... Anyway on this specific property, it seems to me something more general like product (P1056) (but that in itself is perhaps not suitable) would be best. ArthurPSmith (talk) 19:21, 24 June 2016 (UTC)
"Positively reinforces" / "negatively reinforces", or "intensifies" / "suppresses", seem a reasonable level of generality to me; no?
There is an EWPHP id, I wasn't sure how to write it, since the full name of the project is long: "EWPHP ID", all uppercase? How do other properties handle naming? Sj (talk) 17:50, 27 June 2016 (UTC)

as percentage[edit]

   Under discussion
Description percentage of the parent value
Data type Number
Domain numeric value
Allowed values +/-#,##0.0000
Allowed units percent
Example Senior (Q1358789) ÷ population (Q33829) × 100 → xx.xx
See also water as percent of area (P2927)
Motivation – Needful qualifier for vote and election results

votes received (P1111)

eligible voters (P1867) 1,745,635
ballots cast (P1868) 1,244,987
as percentage (Pxxxxx) 71.32 qualifier
total valid votes (P1697) 1,220,394

I found no solution saving a percentaged value related to a numeric value


Symbol plain light blue.svg New proposal --Plagiat (talk) 17:41, 24 June 2016 (UTC)

  • Pictogram voting comment.svg Comment this seems like the sort of thing that should be calculated as required rather than stored as a property? Thryduulf (talk) 00:44, 25 June 2016 (UTC)
    • I thought about this also. But as example: I generate user defined voting reports from municipalities of Bavaria (Germany), the maximum is round about 6,400 calculations. I am not sure, what way is faster and cheaper, calculate or query. --Plagiat (talk) 15:54, 25 June 2016 (UTC)
  • Pictogram voting comment.svg Comment Maybe I may use conversion to standard unit (P2442) --Plagiat (talk) 16:23, 25 June 2016 (UTC)
  • Pictogram voting info.svg Info Additional argument: Querying a single electoral constituency delivers all needed / available data. --Plagiat (talk) 11:05, 26 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose This can be calculated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 29 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose I don't think wikidata should be used as a store to speed up presentation of data. Even a million calculations would be less than a second on just about any device these days. Maybe if there are properties where this is a common issue we could have a javascript gadget that does the calculation as a convenience for people looking at wikidata. Anyway, no I don't think this should be a property. ArthurPSmith (talk) 17:55, 30 June 2016 (UTC)
  • Symbol support vote.svg Support can't necessarily be calculated
    --- Jura 17:57, 30 June 2016 (UTC)

male form of label[edit]

   Under discussion
Description male form of name of an element
Represents male (Q6581097)
Data type Monolingual text
Domain terms
Example horse (Q726) => stallion / gelding / colt (English (Q1860))
hundo (Q144) => virhundo (Esperanto (Q143))
politikisto (Q82955) => politikistulo (Ido (Q35224))
dramatan (Q33999) => hidramatan (Volapük (Q36986))
Haushuhn (Q780) => Hahn / Gockel (German (Q188))
ondernemer (Q131524) => zakenman (Dutch (Q7411))
See also female form of label (P2521)

Wikidata currently already has a property to indicate a female form of a name of an item. This proposed property has the same function but for a male form of a name of an item. Some words have besides a female form also a male form in many languages and some languages even allow for constructing such words by means of prefixes (Esperanto: vir-, Volapük: hi-) and suffixes (Ido: -ul-). Robin van der Vliet (talk) (contributions) 19:37, 26 June 2016 (UTC)

  • Symbol strong support vote.svg Strong support due to gender mainstreaming - used in Germany in many animal labels --Plagiat (talk) 10:57, 28 June 2016 (UTC)
  • Pictogram voting comment.svg Comment "Stallion" is not the only male form of "Horse"; others include, for example, "Gelding" and "Colt". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 29 June 2016 (UTC)
    • Then we can also add those words at the same time to the entry of the horse. Please note that "gelding" only applies to castrated male horses and "colt" only to young male horses.

  • Pictogram voting comment.svg Comment I'm not convinced of the usefulness of this property given some of the samples provided. female form of label (P2521) is mainly used for professions and titles. Infoboxes in some languages make use of that. Can we see infoboxes where the above samples are being used? For general lexical experiments, please use Wiktionary.
    --- Jura 16:18, 29 June 2016 (UTC)


   Under discussion
Description volume of units that do or can pass through or be transported by the object (e.g. trains per hour, passengers per day, kilobits per second)
Represents Throughput (Q1383412)
Data type Number
Template parameter "capacity" in en:template:Infobox roller coaster
Domain transport networks, computer networks, rollercoasters, anything with a throughput
Allowed values positive numbers
Allowed units units of rate e.g. kilobit per second (Q2269250), Passengers per hour per direction (Q7142610), cubic metre per second (Q794261), etc.
See also maximum capacity (P1083)

I discovered this was missing when trying to assist with the query Help with defining Roller Coaster properties at Project chat where it is required for "capacity" (meaning in that case "number of riders per hour"), but I think there is a need for a more general property than one specific to roller coasters. Our existing "capacity" maximum capacity (P1083) property serves a different (but not unrelated) purpose, being used as a static measure of the number of people able/allowed in one space at any given time.

In different fields the throughput is variously quoted as maximum theoretical, maximum actual, average, nominal or (less often) minimum value so I propose that these are specified with qualifiers (e.g. Mathematics Genealogy Project ID (P549) maximum (Q10578722)) rather than having separate properties. "Capacity", "nominal throughput", etc. should be added as English aliases though.
I've included data rates along with physical rates here, but I'm open to splitting them into separate properties if others would prefer as they are clearly related but not necessarily identical concepts. Thryduulf (talk) 11:06, 1 July 2016 (UTC)