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 Sports Sister projects
Economics Transportation Natural science Property metadata

See also[edit]

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. 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 2017/06.

Generic properties[edit]

Muzzle velocity[edit]

   Under discussion
Description the speed of a projectile at the moment it leaves the muzzle of a gun
Represents muzzle velocity (Q920165)
Data type Number (not available yet)
Template parameter velocity at en:Template:infobox weapon
Domain weapon
Allowed values number
Allowed units m/s
Example AK-47 (Q37116) → 715m/s
Robot and gadget jobs probably

(Add your motivation for this property here.) GZWDer (talk) 09:04, 17 January 2017 (UTC)

  • Symbol oppose vote.svg Oppose The notable variables for muzzle velocity are length of the barrel and the characteristics of the ammunition. How would this property allow both a weapon and a very specific manufacture of ammunition to be defined? One suggestion is to have a item:weapon property:fires_ammunition item:ammunition triple with a qualifier of muzzle velocity (Q920165). Or perhaps the qualifier should be Muzzle energy (Q1410940) instead? Dhx1 (talk) 12:34, 8 February 2017 (UTC)
  • Symbol support vote.svg Support There are variables, but they can be handled with qualifiers. This is a useful and specific specification for several weapons. For several weapons there may be a simple muzzle velocity specified in a source. For others it may have more breakdown for different ammunition or use cases, but that can be determined per the subject and is not a reason to stop this proposal. Josh Baumgartner (talk) 09:34, 19 April 2017 (UTC)
    @Joshbaumgartner, GZWDer: Please provide a working scheme and examples. It semm a good practice to me to decide on how to use b property before creating it. author  TomT0m / talk page 11:25, 20 May 2017 (UTC)
  • Symbol support vote.svg Support --Micru (talk) 07:53, 24 April 2017 (UTC)
  • Symbol support vote.svg Support per Josh Baumgartner. - Brya (talk) 15:53, 7 May 2017 (UTC)
  • Symbol support vote.svg Support Music1201 talk 23:53, 17 June 2017 (UTC)

firing range[edit]

   Under discussion
Description firing range of weapon
Data type Number (not available yet)
Template parameter |range= in en:Template:Infobox Weapon
Domain weapon
Allowed values number
Allowed units metre (Q11573), kilometre (Q828224)
Example QJY-88 (Q6458018) → 1000m
Robot and gadget jobs probably

(Add your motivation for this property here.) GZWDer (talk) 09:14, 17 January 2017 (UTC)

  • Pictogram voting comment.svg Comment "firing range" is often the term used to describe a place where one can fire guns at targets. I think "weapon range" or perhaps "deadly range" would be a better name for this property. ArthurPSmith (talk) 19:22, 17 January 2017 (UTC)
  • Symbol support vote.svg Support with a better name, per Arthur. Added "kilometre" as an allowed unit, for artillery. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 17 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose in the current form because the range of a weapon has many variable factors including the ammunition type, test conditions (weather, firing position), etc. For example, how would someone determine the range of a boomerang (Q131536)? I thought about whether determination method (P459) could be a mandatory qualifier to determine how the range was calculated, but am not aware of standards which may be used to test the range of weapons. Are there standards which could be referred to with a determination method (P459) property? If so, I'd be happy to change this vote to one of support as a testing standard should remove the variable factors. Dhx1 (talk) 12:23, 8 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose As Dhx1. Weapon range is depending on several parameters and an interval should be used instead. Snipre (talk) 21:00, 22 February 2017 (UTC)
    • Pictogram voting question.svg Question @Snipre:, can you clarify? Specifically, any idea on how such an interval idea would be implemented? Josh Baumgartner (talk) 09:38, 19 April 2017 (UTC)
      • @Joshbaumgartner: You have several types of ammunition which can be used on one weapon, so the first as explained above is to provide the ammunition type tested to define the range using determination method (P459). The best is to modify the scope of the property and to put not the firing range but the maximal lethal distance. I am not a spacialist so the best is to ask to people working in the weapon domain to provide the correct definition. Snipre (talk) 05:50, 21 April 2017 (UTC)
  • Symbol support vote.svg Support Knowing the effective range a weapon can be used to is very valuable. There may be many factors that go into determining what that range is for a particular weapon, but they are not always published. When they are available, of course qualifiers should be added. However, the fact that they are not always available is not a valid reason to not have a way to add the very important and pertinent information. If we don't have a property such as this, how do we capture the data in WD from a source that says, "the effective firing range of the Cannone da 65/17 modello 13 (Q162404) is 6.8 km"? Josh Baumgartner (talk) 09:18, 17 April 2017 (UTC)
  • Symbol support vote.svg Support (with a better name, perhaps "effective range" or "maximum effective range") per Joshbaumgartner. Thryduulf (talk) 21:53, 18 April 2017 (UTC)
  • Symbol support vote.svg Support--Micru (talk) 07:54, 24 April 2017 (UTC)
  • "effective range" and "maximum range" are two different things: for handguns the latter can easily be two or three (or more) times as much as the former. I would like to see two separate properties. (I agree that "firing range" is a place where guns are fired: maybe "effective range of gun"?). - Brya (talk) 15:59, 7 May 2017 (UTC)

only valid for subset[edit]

   Under discussion
Description This should only be used as a qualifier. It denotes that the statement isn't true for all instances but only for a subset.
Data type Item
Example Rectus abdominis muscle (Q275150) innervated by (P3189) Sixth intercostal nerve (Q27058097) → this property → Unknown value
See also applies to part (P518), valid in period (P1264), valid in place (P3005)

I take information about innervation from Anatomy and Human Movement Structure and Function SIXTH EDITION (Q27050364). It tells me that in sometimes Rectus abdominis muscle (Q275150) is innervated by Sixth intercostal nerve (Q27058097) while in other cases it isn't.

I want this property to be able to enter this kind of knowledge in Wikidata. I'm personally unsure whether this is the best way to model this domain. If someone has other suggestions I'm happy. ChristianKl (talk) 14:03, 24 January 2017 (UTC)

  • Maybe use applies to part (P518)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 24 January 2017 (UTC)
    • No, I'm pretty sure that's a different meaning than ChristianKl intends, but maybe also indicates the name is confusing. I think the meaning wanted here is effectively the difference between "sometimes" and "always". How to model that in wikidata? ArthurPSmith (talk) 18:27, 24 January 2017 (UTC)
      • I also think that applies to part (P518) has a slightly different meaning. I think it's worthwhile to have properties that can make precise statements about issues like this and it's not good to overload applies to part (P518) with slightly different meanings. A human might understand what's meant when he reads the data but an automated system might not. ChristianKl (talk) 09:56, 25 January 2017 (UTC)
  • Well, you need an item for the subset anyway ? So, why not just put the statement in that item and left what is valid in every case in the upper one ? author  TomT0m / talk page 21:49, 25 January 2017 (UTC)
It might be that we have a source that says that this is true for 50% of the population. This information could be filled in. ChristianKl (talk) 09:09, 27 January 2017 (UTC)
How do you express "50% of the population" ? The set is not identified. Isn't this the notion of incidence (Q217690) View with Reasonator View with SQID or something similar you're looking for ? Or you're looking for something similar to disjoint union of (P2738) View with SQID or subclass of (P279) qualified with a numerical value representing this ? author  TomT0m / talk page 11:30, 27 January 2017 (UTC)
@TomT0m:I think it's worth having a specific property for this to allow for automated interaction with the data. If you think there's a specific way this data can already be presented I invite you to edit the example of Rectus abdominis muscle (Q275150) accordingly. ChristianKl (talk) 07:44, 2 February 2017 (UTC)
@TomT0m, ChristianKl: You can use proportion (P1107) to express this. --Swpb (talk) 17:19, 15 February 2017 (UTC)
@Swpb: If you think this property can be used here, could you edit the linked example accordingly? ChristianKl (talk) 17:52, 15 February 2017 (UTC)
  • Pictogram voting comment.svg Comment I added a few "see also" above.
    --- Jura 11:47, 26 March 2017 (UTC)

Enciclopedia Italiana ID[edit]

   Under discussion
Description identifier for the Enciclopedia Italiana on Treccani website
Represents Enciclopedia Treccani (Q731361)
Data type External identifier
Template parameter "1" in w:it:Template:Enciclopedia Italiana
Domain generic
Allowed values [a-z0-9-]
Example Germany (Q183) → "germania"
Formatter URL$1_(Enciclopedia-Italiana)/
See also Enciclopedia Treccani ID (P3365)

The site hosts the text of the original "Enciclopedia Italiana di scienze, lettere ed arti" (1929-1937) under the "namespace" _(Enciclopedia-Italiana). The aim of the property is to distinguish between this one and "Enciclopedia Treccani" (that, eventually, should be renamed in "Enciclopedie on line", like it is written in the website), that, as the name says, is born online (2011).

They obviously are two distinct things (e.g. the two articles about Germany: [1][2]), and I think we should keep the two respective properties separated. --Horcrux92 (talk) 10:35, 25 January 2017 (UTC)

  • Pictogram voting comment.svg Comment if I understand correctly, these id's can be entered now using Enciclopedia Treccani ID (P3365) but for many of items we could end up with 2 (or 3 or more?) id's? I'm not sure this is really a problem, I think the intent with Enciclopedia Treccani ID (P3365) was to cover everything on ArthurPSmith (talk) 20:04, 25 January 2017 (UTC)
    The fact is that they are two completely different works. Like for the DBI, for example, we have a distinct property, even if it is hosted always in Obviously it is technically possible to insert all the different encyclopedias under the same property, but I think the most-known ones should have distinct properties. The goal is to have a precise and non-ambiguous ontology. --Horcrux92 (talk) 09:21, 26 January 2017 (UTC)
    If the two are completely different made the description of this property could make it clearer which one is meant, so it won't be used wrongly? ChristianKl (talk) 17:30, 7 March 2017 (UTC)
    • "Enciclopedia Italiana" (properly Enciclopedia Italiana di scienze, lettere ed arti) is the original name of the papery encyclopedia, and of its transposition online of 2015. Example
    • "Enciclopedie online" (P3365) is the born-on-Internet Treccani's encyclopedia of 2011. Example
    The description above is already correct; P3365's description must be corrected only if it will be decided to create this new property.--Horcrux92 (talk) 10:44, 8 March 2017 (UTC)
  • Symbol support vote.svg Support Having a distinct property for this particular branch of is a good idea. Jonathan Groß (talk) 09:26, 10 April 2017 (UTC)
  • Pictogram voting question.svg Question Why is this taking so much time? --Horcrux92 (talk) 17:11, 4 June 2017 (UTC)
    The disambigution with Enciclopedia Treccani ID (P3365) is unclear in the description of this property. As far as the name goes, it's not clear to me why it's not labeled "Enciclopedia Italiana ID". ChristianKl (talk) 10:40, 16 June 2017 (UTC)
    Yes, the label should be "Enciclopedia Italiana ID". I've changed the proposal schema.
    To sum up:
    • Property "P3365"
      (new) label: "Enciclopedie online ID"
      (new) description: "identifier for the Enciclopedie online on Treccani website"
    • New property
      label: "Enciclopedia Italiana ID"
      description: "identifier for the Enciclopedia Italiana on Treccani website"
    --Horcrux92 (talk) 13:31, 17 June 2017 (UTC)
    Given those descriptions I still fear that people will be frequently confuse the two. ChristianKl (talk) 19:47, 17 June 2017 (UTC)
    Is this relevant? Does the fact that two properties just appear similar prevent us from distinguish them? --Horcrux92 (talk) 10:13, 19 June 2017 (UTC)
    I mean, for DBI (that is alwais on Treccani's website) we have a distinct property. We don't want to create a property for "Enciclopedia Italiana" (that has even a greater history and importance!) only because its name may be confused with another one? If that is the problem, we can use a more detailed description like «identifier for the Enciclopedia Italiana on Treccani website; the URL ends with "(Enciclopedia-Italiana)"» or something similar. And we will also use the property different from (P1889). --Horcrux92 (talk) 10:18, 19 June 2017 (UTC)

CPUID code[edit]

   Under discussion
Description CPUID identification code
Data type String
Template parameter "cpuid" in en:template:Infobox CPU
Allowed values hexadecimal string
Example Core i7-6700 (Q28739510) → 506E3 (see

CPUID code to identify a specific CPU microarchitecture. List of these codes can be found here : Maybe other codes can be created too for family, model and stepping (in decimal) Mikayé (talk) 14:46, 10 February 2017 (UTC)

Pictogram voting comment.svg Comment - no formatter URL to link directly to these values? ArthurPSmith (talk) 16:46, 10 February 2017 (UTC)
  • Symbol support vote.svg Support. I took the liberty of adding the formatter URL. --Swpb (talk) 16:37, 15 February 2017 (UTC)
    • @Swpb, Mikayé: That formatter URL does NOT work with the supplied example of 506E3 - it gives an invalid CPU ID error. ArthurPSmith (talk) 20:02, 16 February 2017 (UTC)
    • The formatter is not good. The value should be the value returned by the cpuid instruction, not the id on cpu-world website. I gave the website as an example of source to obtain the value for a specific CPU. I think Swpb made a confusion between the two cpuid. Maybe the cpu-world id can be another property but that's another story... I removed the formatter. Mikayé (talk) 10:27, 17 February 2017 (UTC)
  • Symbol support vote.svg Support. This looks very useful to me. YULdigitalpreservation (talk) 14:50, 16 February 2017 (UTC)
  • I would like the description to contain more information about what the item is about, so that people who don't already know the abbrivation have an ID of what it's about by reading it. @Mikayé: ChristianKl (talk) 10:45, 20 February 2017 (UTC)
  • BA candidate.svg Weak oppose Intel documentation for how this code should be formatted for Intel processors is provided in figure 3-6 on page 3-204 of Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 2A. AMD documentation is provided at the top of page 11 of AMD CPUID Specification. This proposal concerns me a little bit because it is actually an accumulation of multiple identifiers. I assume this accumulation is meant to be a mixture of Base Family (4 bits), Base Model (4 bits), Extended Family (8 bits), Extended Model (8 bits), but this proposal does not make it clear how these identifiers are to be arranged together. I propose an alternative approach which is to create 4 distinct properties for CPUID Base Family, CPUID Base Model, CPUID Extended Family and CPUID Extended Model. You may also want to investigate whether a CPUID Stepping (4 bits) property could be useful as well to capture revisions/manufacturing variants of each CPU. Dhx1 (talk) 14:06, 22 March 2017 (UTC)
  • Pictogram voting comment.svg Comment We need to be clear that the "CPUID code" being talked about here is part of the x86 / x86-64 CPU architecture, and so doesn't exist on CPUs of other architectures such as ARM, SPARC, POWER, MIPS, etc. (Those other CPU architectures may in some cases have similar facilities, but they probably won't be called "CPUID" and will likely have a different format.) So, I think the property proposal should be amended to clarify that this property is only for x86/x86-64 CPUs. Maybe change the label to "x86 CPUID code" or something like that to make it clear. SJK (talk) 22:20, 1 April 2017 (UTC)

Ruud Koot
Pictogram voting comment.svg Notified participants of WikiProject Informatics ChristianKl (talk) 13:09, 24 May 2017 (UTC)

category contains[edit]

   Under discussion
Data type Item
Template parameter in SPARQL form, on Commons c:Template:Category contains (experimental)
Domain category items
Allowed values class items
Example Category:Grade I listed buildings in Bedfordshire (Q8497784)building (Q41176),
with qualifiers
* located in the administrative territorial entity (P131)Bedfordshire (Q23143),
* heritage status (P1435)Grade I listed building (Q15700818)
Robot and gadget jobs Move existing statements on category items using is a list of (P360) to use this property instead
See also is a list of (P360), category's main topic (P301), category combines topics (P971)

We currently have 12,434 items that are categories using is a list of (P360) for this purpose (, using this format. This has been approved in an RFC, however before that close the question seemed to create a lot of dispute at Property talk:P360.

This kind of specification allows software like Reasonator to generate automatic lists of items with properties that appear to meet the criteria, which can then be compared with the current content of the actual list or category -- see for example the list offered by Reasonator on its page [3] for the list article Grade I listed buildings in Bedfordshire (Q5591762).

Coming back to this debate a year on, it seems to me it would be useful to separate the two into two parallel properties -- P360 specifically for lists, and this property specifically for categories. This would then mean that all uses of P360 would be for lists, all uses of the new property would be for categories. This would avoid the 'bad smell' of using a property called "is a list of" on categories, which definitely shouldn't be confused with lists; and it could help query performance, since excluding lists or excluding categories can be costly. Jheald (talk) 17:02, 11 February 2017 (UTC)

  • Symbol support vote.svg Support so I assume you would transition all the P360's on categories to this new property? I think it's fine to be more specific like this, so I support it. ArthurPSmith (talk) 18:30, 13 February 2017 (UTC)
  • Symbol support vote.svg Support per the thorough consideration given above. --Swpb (talk) 16:25, 15 February 2017 (UTC)
  • Symbol support vote.svg Support. Thank you for proposing this. I agree that this would make creating lists easier and more flexible. YULdigitalpreservation (talk) 14:52, 16 February 2017 (UTC)
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 24 February 2017 (UTC)
  • @Jheald: The property is currently missing an English description. ChristianKl (talk) 07:19, 25 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose category combines topics (P971) should do.
    --- Jura 10:31, 25 February 2017 (UTC)
    @Jura1: That property fails to express how the categories are combined. It does not contain sufficient information to automatically be able to write a search query to find corresponding items, in the way is a list of (P360) does, which this property would be modelled on.
See also on Commons, the positive response from User:Astinson (WMF) (diff) to the idea of building information of this kind on Commons, with similar potential for automated searches, as part of preparations towards structured data there. This property would help that a lot, for when there are parallel categories here to Commons categories. Jheald (talk) 18:37, 2 March 2017 (UTC)
I think it works even better than is a list of (P360). Have a look at the first sample: Q7068416.
--- Jura 20:40, 2 March 2017 (UTC)
@Jura1: The use of see also (P1659) is interesting, I hadn't seen that before with category combines topics (P971). I'm not sure that "see also" is quite right, perhaps some more specific qualifier eg "object of" might be an idea. But the shape is interesting.
I suppose I am used to is a list of (P360), and there are a number of uses on lists that could be transferred straight over. (And, equally, a number of cases where we have parallel lists and categories, that I can see advantages in treating in the same way, to result in similarly parallel specifications).
Something I like about P360 is that it tells you immediately and clearly what the subject matter is: this is a list of people; this is a list of paintings; etc, that then is specified in more detail with the qualifiers -- which I miss with your design. (Indeed, you don't seem to be specifying P31 Q5 at all -- which is definitely information that it is useful for machine-parsing the category).
But I am interested -- what do you see as the advantages of your model of using P971; and what disadvantages do you see with the similar-to-P360 approach? Jheald (talk) 21:29, 2 March 2017 (UTC)
You are right, the sample could include Q5 as well. I did suggest a more specific qualifier, but people weren't interested or preferred P1659. As the result on my application is the same, it doesn't matter much:
It works for links on Wikidata:Database reports/items without claims categories/eswiki allowing to add statements to items lacking them.
--- Jura 21:35, 2 March 2017 (UTC)
@Jura1: But what do you see as particular advantages or disadvantages between the two forms? I've set out above why on balance I like the idea of something a bit more similar to is a list of (P360), which is already widely deployed. But what do you think are reasons to prefer or not prefer one over the other? Jheald (talk) 21:47, 2 March 2017 (UTC)
P971 is closer to Wikidata's incremental way of building things. It allows to specify parts that may not be included in statements to be added. I use less P360 as I think it relies too much on qualifiers. I don't see much of a problem converting the few uses of P360 on categories to category combines topics (P971).
--- Jura 21:57, 2 March 2017 (UTC)
@Jura1:, for me, your example of Category:Dutch politicians (Q7068416) is distinctly different than this proposal. It claims that Category:Dutch politicians (Q7068416) -> category combines topics (P971) -> Kingdom of the Netherlands (Q29999) and politician (Q82955). But neither of those are sub-categories or topics under Category:Dutch politicians (Q7068416), which is the point of this proposal as I understand it, and so category combines topics (P971) isn't really valid to use for the purpose proposed here. Josh Baumgartner (talk) 16:26, 1 May 2017 (UTC)
I think both can be used to build the same query. P971 just offers more flexibility. The exception may be sample you mention below.
--- Jura 03:42, 2 May 2017 (UTC)
  • Symbol support vote.svg Support after reading the above discussion I'm more convinced by Jheald's reasonings in support of this method than Jura1's alternatie. Thryduulf (talk) 08:35, 12 April 2017 (UTC)
  • Pictogram voting question.svg Question Category:Aircraft by registration (Q29642098) has more than 70,000 sub-categories. Would each of these (that have a WD item anyway) have its own claim under Category:Aircraft by registration (Q29642098)? Josh Baumgartner (talk) 16:26, 1 May 2017 (UTC)
  • @Jheald: I don’t really get the point. We already know from the item type if it’s a list or a category, so there is no need for two properties. I don’t really understand the « excluding list or categories » need as it’s enough to just select lists ( instance of wikimedia list article ) or categories or both and it’s just routine not costly sparql. No need to exclude anything. Did I miss anything ? author  TomT0m / talk page 11:36, 20 May 2017 (UTC)
  • @Jheald: Can you add a description for this property? ChristianKl (talk) 11:05, 22 May 2017 (UTC)

NCJ ID[edit]

   Under discussion
Description identifier for a publication, report, article or audiovisual product, in the United States' National Criminal Justice Reference Service database
Represents National Criminal Justice Reference Service (Q6972009)
Data type External identifier
Template parameter en:Template:NCJ
Domain publication, report, article, or audiovisual product
Allowed values \d{6}
Example Measures of Gun Ownership Levels for Macro-Level Crime and Violence Research (Q28798208)203876
Formatter URL$1
Robot and gadget jobs Yes

Possible a useful database for source metadata. GZWDer (talk) 17:05, 18 February 2017 (UTC)


Cyworld ID[edit]

   Under discussion
Description ID of the subject at Cyworld
Represents Cyworld (Q29760)
Data type External identifier
Template parameter
Domain people, organization
Allowed values \d+
Example Kim Sa-rang (Q464663) → 27684413
Formatter URL$1
Robot and gadget jobs From enwiki and kowiki

Note: the current website account on (P553)=Cyworld (Q29760) should be replaced by the url in pages which redirects to, such as> so that Baek Chan (Q12597932) have Cyworld ID=27944834. GZWDer (talk) 18:00, 18 February 2017 (UTC)


alt attribute[edit]

   Under discussion
Description qualifier to specify alternative text (alt text) that is to be rendered when the element to which it is applied cannot be rendered. For the legend, use P2096 instead.
Represents Alt attribute (Q1067764)
Data type Monolingual text
Template parameter « image », « blason » for w:fr:Infobox Biographie2
Example no alternative anymore for this
Planned use qualifier only
See also media legend (P2096)
Français : Cette propriété est nécessaire, notamment, pour les infobox important des données de Wikidata. En effet, les personnes utilisant Wikipédia sans images (notamment, les personnes ne bénéficiant que d'une faible connectivité à l'Internet ou les aveugles) ne peuvent pas bénéficier d'une description de l'image qu'elle ne voit pas dans ces infobox important des images de Wikidata. Contrainte : qualifier pour les propriétés du type de données Commons media uniquement.
English: This property is needed because we use a lot of infobox importing Wikidata properties on our wikis. For now, peoples navigating without images (peoples with low Internet connectivity or blind peoples) can't access a description of the missing images in these infobox. Constraint: qualifier to be used for properties with commonsMedia datatype only.

Simon Villeneuve (talk) 13:48, 23 February 2017 (UTC)

Black and white photography of a smiling black man with a white hat and a dark jacket holding a trombone in front of him with his both hands with wood wall behind.
w:en:Al Grey by William P. Gottlieb (1980s)
  • Symbol support vote.svg Support obviously, but it will need a good documentation on how to write a good Alt attribute. VIGNERON (talk) 14:20, 23 February 2017 (UTC)
  • Symbol support vote.svg Support Seems usefull. — Metamorforme42 (talk) 14:58, 23 February 2017 (UTC)
  • Pictogram voting comment.svg Comment I think this is a good idea; however maybe a longer property name would be helpful? Not everybody is familiar with HTML property names. "image caption" perhaps? ArthurPSmith (talk) 18:15, 23 February 2017 (UTC)
    • Hmm, I just noticed media legend (P2096) which appears to be intended for exactly this purpose. Why do we need a new property? ArthurPSmith (talk) 18:16, 23 February 2017 (UTC)
      • I don't care of the name. Choose what you want.
        When we put an image on a wiki, we do it in a form similar to this : [[File:NAME OF THE FILE (=P18)|thumb|upright=|alt=|Image caption (=P2096)]]. The image caption isn't the image description. I have put an example above with this wikicode : [[File:Al Grey (Gottlieb).jpg|thumb|alt=Black and white photography of a smiling black man with a white hat and a dark jacket holding a trombone in front of him with his both hands with wood wall behind.|[[:w:en:Al Grey|Al Grey]] by William P. Gottlieb (1980s)]]. Simon Villeneuve (talk) 20:01, 23 February 2017 (UTC)
        • @ArthurPSmith: you probably should read en:alt attribute. The alernative is not a caption (thought it's close) but a specific W3C recommandation used in Wikicode (and elsewhere) for accessibility purpose. Cdlt, VIGNERON (talk) 21:19, 23 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose The appropriate "alt" value is dependent on the context where the image is used. In the example above, for example, it should be different when used on the Wikipedia articles "Pith helmet", "Trombone", "Al Grey" or "William P. Gottlieb". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 23 February 2017 (UTC)
    • @Pigsonthewing:, no media legend (P2096) could be dependent of the context but the alternative if just a textual version of a media, it's not dependent of the context. Cdlt, VIGNERON (talk) 21:41, 23 February 2017 (UTC)
      • @VIGNERON: That's incorrect. The alternative text used for an image on any Wikipedia depends strongly on context. Alternative text for wikis is made up of the alt text attribute and the image caption, as any assistive technology will read both of them. Secondly, if the value of this property is to be used in an infobox, then editors need to be aware that irrelevant information is quite unlikely to be acceptable: in the example image above you certainly wouldn't be describing the wooden wall in an en-wp infobox, as it's completely unrelated to the subject of the image. -- 00:53, 24 February 2017 (UTC)
  • The description text does depend on context but context is partly given. If the Al Grey picture is stored on the item for Al Grey as the main image the context is clear enough that describing the wall behind him is besides the point. ChristianKl (talk) 21:46, 24 February 2017 (UTC)
  • BA candidate.svg Weak oppose with current name/description. The description and name of the property should make clear of what it's about and how it is supposed to be used. ChristianKl (talk) 21:32, 23 February 2017 (UTC)
    • @ChristianKl: the World Wide Web Consortium defined in 1995 (HTML 2.0, RFC 1866) exactly and precisely how an alt attribute should be done and used. Cdlt, VIGNERON (talk) 21:41, 23 February 2017 (UTC)
      • That doesn't change anything about the fact that this property proposal currently doesn't have a satisfactory description. ChristianKl (talk) 21:42, 23 February 2017 (UTC)
        • Yes, maybe Simon Villeneuve (talkcontribslogs) didn't write a perfect description (errrare humanum est) but the use is very clear, there is literally hundred of thousand documents on the web describe this attribute so the scope is quite limpid. Cdlt, VIGNERON (talk) 21:46, 23 February 2017 (UTC)
          • @VIGNERON:When we decide whether or not to accept a proposal, it's about deciding whether a given proposal is up to the task of being good for modeling a problem domain. It's worth to wait till we have a good way to model a problem before we create a property. ChristianKl (talk) 07:18, 24 February 2017 (UTC)
            • @ChristianKl: the best minds of the Interent are modeling this attribute for more than 22 years now, it's even notable enough to have it's on Wikipedia article; I think it can be safely assumed that the problem is well known and that the modeling solution is good enough. But of course, if you have suggestions of improvements, don't hesitate to share them. Cdlt, VIGNERON (talk) 08:07, 24 February 2017 (UTC)
              • @VIGNERON:If you pretend that the problem that we face on Wikidata when describing this property is exactly the same that's faced by the creators of the html standard, that's a good way to get me to oppose your proposal. One of the reasons the designers of the spec choose "alt" is that it's short and thus requires little bandwith. We have different design constraints and before I support the proposal I want name and description that serves our design contraints well.
Wikidata properties have a name and a description. When it comes to making a property proposal it's important to make them as clear as possible. If this property is supposed to be used as a qualifier, look at the way other qualifiers are described. There description texts usually doesn't talk about the fact that it's a property. The description of a property is also not Wikitext but a common string. That makes the current description text unworkable.
Besides if you think there so much good work on how to model this property, could you please link to three different software packages and investigate why the choose a specific name and which description they use? Maybe there's really a best practice as far as software libraries go that don't try to minimize text length. ChristianKl (talk) 21:58, 24 February 2017 (UTC)
We show you the Moon and you speak about the finger... Simon Villeneuve (talk) 12:55, 25 February 2017 (UTC)
  • Symbol support vote.svg Support A bit shocking we don't have this already. Some image suppliers may already provide it. (Though I agree with the comment up thread, that's it definitely a skill to learn how to write these). Jheald (talk) 00:02, 24 February 2017 (UTC)
  • Currently the proposal doesn't specify that it's limited to providing alt texts for images. What kind of other alt texts would it provide? Is there a good reason we don't go with the enwiki name of "alt attribute" or "alt attribute of image"? ChristianKl (talk) 07:23, 24 February 2017 (UTC)
    • « alt », « alt text » or « alt attribute » are synonyms, they are interchangeable so we can change for either one. As I added to the description of this proposal, it can be use on « every properties with commonsMedia datatype » (it will be mostly image but it's not limited to them, see the HTML rules and accessibility rules for more information). Cdlt, VIGNERON (talk) 08:03, 24 February 2017 (UTC)
      • They might be synonyms but when we create a Wikidata property we still have to decide which one serves our purposes the best. ChristianKl (talk) 07:29, 25 February 2017 (UTC)
        • @ChristianKl: yes, obviously... and? What do you propose? I've shortened the description and changed for wikipedia's articles names as label, fell free to propose better! (and this is a wiki, we can still change the label, description and uses of the property after the creation). Cdlt, VIGNERON (talk) 08:16, 25 February 2017 (UTC)
          • I want that people who make a property proposal (or want it to be implemented) put in the work to think about how best to create the names and descriptions of they proposal they want to get adopted. ChristianKl (talk) 18:12, 25 February 2017 (UTC)
            • @ChristianKl: And I want world peace. For this proposal, what do you think of the new label and description? Cdlt, VIGNERON (talk) 18:30, 25 February 2017 (UTC)
              • @VIGNERON: Status quo, seems to be that nothing is happening with the property given that I did nothing to move it forward. Given that people pointed to the huge amount of prior art I still think that it's worthwhile for someone to check how our label/description relates to the prior art of other projects. ChristianKl (talk) 21:59, 11 May 2017 (UTC)
  • @Graham87: for your expert advice, please. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 24 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose – I came to say the same thing as Andy ... the appropriate alt text for an image depends on its context. This is described in the "Importance of context" section of Wikipedia's page about alternative text. Graham87 (talk) 12:26, 24 February 2017 (UTC)
  • Symbol support vote.svg Support I just want to vote my support here - particularly with the longer name "alt attribute". I understand the context concern - but we have that generally when infoboxes are used in wiki's, a local editor can decide to override the information provided from wikidata with their own text if necessary. Context matters, but a verbal description of the image or other media can be written in a reasonably generic way that would work in most contexts. Maybe wikidata usage instructions for this property could mention this issue. ArthurPSmith (talk) 16:57, 2 March 2017 (UTC)
  • Symbol oppose vote.svg Oppose P2096 is mainly here as Commons isn't quite ready yet, but I don't think we should expand this further.
    --- Jura 11:34, 26 March 2017 (UTC)
  • Symbol wait.svg Wait as it may be more relevant for Commons rather than Wikidata. ~nmaia d 17:05, 11 May 2017 (UTC)
  • Strong Symbol support vote.svg Support This would be very useful - and I'm surprised it's not already implemented. In its most basic case of just describing what is in the image for visually impared people, it would be very useful. More complicated situations where that description needs to be adapted for different situations can come later, if needed. Thanks. Mike Peel (talk) 22:56, 3 June 2017 (UTC)

Finnish Business and Organization Number[edit]

   Under discussion
Description unique identifier for a business or organizational entity registered in Finland
Data type External identifier
Domain companies (Q333920)
Allowed values [0-9]{7}-[0-9]
Example Sanoma (Q1540297) → 1524361-1

I started mapping out Finnish media companies and organizations owned by the municipalities. In both cases organizations and businesses form complex networks. At the same time brand names are some times used loosely. To map out and understand networks it becomes important to be able to browse for information from the governmental registry and to be able to be specific about which official organization or business is meant. Thus the need for official business numbers. Petrikola (talk) 20:51, 28 February 2017 (UTC)


PfaF ID[edit]

   Under discussion
Description identifier of a plant taxon, in the Plants For A Future database of uses of plants and their parts
Data type External identifier
Domain plant taxa (taxon (Q16521))
Allowed values [^\s\/]+
Example Castanea sativa (Q22699)Castanea+sativa
Source Plants for a Future (Q246234)
Formatter URL$1

PFAF ("Plants For A Future") is a database of uses (incl edible and medical) of plants and their parts d1g (talk) 17:56, 15 March 2017 (UTC)

  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:18, 19 March 2017 (UTC)
  • Symbol support vote.svg Support. This looks like a useful property for describing plant uses in Wikidata.
  • Are all entries plants? If so the domain can be more narrow and the name can be "PFaF plant ID". ChristianKl (talk) 08:49, 24 March 2017 (UTC)
    I renamed to "PFaF plant ID". ChristianKl (talk) 12:47, 22 May 2017 (UTC)
  • The datatype should be changed to URL, because this one is not an ID. E.g. Castanea_sativa gives the same result as Castanea+sativa. --Succu (talk) 17:54, 23 May 2017 (UTC)
  • This seems OK. I am not too worried about the datatype. - Brya (talk) 04:23, 25 May 2017 (UTC)

electoral district number[edit]

   Under discussion
Description Number of the constituency/electoral district established by law. Only to be used if the number is established by law, regulation, or other legally-binding decision; not to be used for database identifier numbers which lack legal force, even if contained in a government database.
Data type String
Template parameter n/a
Domain subclasses of constituency (Q192611)
Allowed values no restriction, because different elections use different keys/numbers
Example federal electoral district Neu-Ulm (Q1008451) is a federal electoral district of Germany (Q11703715) with constituency number (Wahlkreisnummer) 255. no label (Q2539878) is a Landtag electoral district (Q18226756) with constituency number 14, California's 53rd congressional district (Q5020115) has constituency number (congressional district number) 53
Format and edit filter validation n/a
Source for example List of constituencies
Planned use election for the German Bundestag in September 2017, US congressional districts
Robot and gadget jobs No.
See also catalog code (P528) Wikidata:Property proposal/District

For elections the territory will be divided in smaller parts. The electoral district will be identified by a unique key. For the election for the German Bundestag the subdivision is set in the Twenty-third Law amending the Federal Elections Act. For correct identifying the official key should be used. The new property will store this key. -Looniverse (talk) 20:19, 30 March 2017 (UTC)

  • Pictogram voting comment.svg Comment if it's just for Germany, you might want to add that at least in the English label or description.
    --- Jura 05:39, 31 March 2017 (UTC)
    No, this property is usable in various elections such as the Australian Federal Election (column DivisionID). --Looniverse (talk) 07:32, 31 March 2017 (UTC)
    • In that case, I'd go with catalog code (P528)
      --- Jura 11:04, 31 March 2017 (UTC)
    • Looniverse I think there is a big difference between Australian "Division IDs" and the fact that California's 3rd congressional district (Q1002522) is number "3". As far as I am aware, the Australian "Division IDs" have no legal standing, they are simply arbitrary ID numbers in a government database; the Australian Electoral Commission (Q1658569) could move to a new database tomorrow, in which those "Division IDs" no longer exist or have different values. By contrast, the fact that Q1002522 has number "3" is actually legally defined, it couldn't be changed to a different number without a legal act (whether legislation, or a legally binding decision of an agency such as California Citizens Redistricting Commission (Q5020315)), whereas the AEC can change "Division IDs" at whim and that wouldn't be an act with legally relevant consequences. So, I don't like the idea of using this proposed property to mix up legally-established identifiers from what are merely arbitrary identifiers in a government database. Officially/legally established identifiers should be kept distinct from arbitrary database identifiers (even if the database is run by a government agency). SJK (talk) 08:12, 1 April 2017 (UTC)
      • SJK In Germany the IDs are set by a law whether it is a federal election, a country election or a communal election. The ID of the constituency is unique for the respective election. So the assign of the results is clearly. The name of the constituency is unique too, but its easier and clearer to use a number. But the ID is unique only in combination with the respective election (the ID #3 for instance is available for the federal election no label (Q1008632), for the country election in Hamburg no label (Q2539837), for the country election in Nordrhein-Westfalen no label (Q1804267)...these are different constituencies in different areas). Looniverse (talk) 11:26, 3 April 2017 (UTC)
        • Looniverse I would argue the property description should be amended to say it is for legally-established numbers only. So if the law provides for a district to have a certain number, this property can be used. Whereas, if it is merely an arbitrary ID from a database, even a government-run database, this property should not be used. This would exclude its use with Australian DivisionIDs, but allow its use with US congressional district numbers. Since you tell me that the German identifiers are established by law (I am taking your word on that), it would be allowed to use this property with German identifier numbers too. My justification is it doesn't make sense to have a property whose values are a mix of legally-established values with values that lack any legal force. Do you agree with that? SJK (talk) 08:18, 4 April 2017 (UTC)
          • SJK I agree with you. Would you please adjust the property description. Thanks. Looniverse (talk) 14:46, 4 April 2017 (UTC)
            • Looniverse I made some changes, are you okay with them? I haven't updated the German description, since I know very little German (almost but not quite zero), and while I could try with Google Translate, it would probably be wrong. I got rid of the use of the word ID and replaced it with number. I think that is better in that it sounds more like something that might be legally binding as opposed to just a possibly arbitrary database key. Since the German word being used is Nummer, I think that is better translated as number. (I realise you probably picked ID not number to reflect that Nummer is more restricted in meaning than Zahl, but the Nummer-Zahl distinction doesn't really exist in English–if the German word was Identifikationsnummer, then ID would be of course right – but in my searches I never see Identifikationsnummer used in conjunction with Wahlkreis, only ever Nummer, especially in the compound Wahlkreisnummer). SJK (talk) 21:09, 4 April 2017 (UTC)
              • SJK Thank you. Now its clearer. In this context the German word Nummer is correct. Looniverse (talk) 10:29, 5 April 2017 (UTC)
  • Pictogram voting comment.svg Comment here in the US we have a complicated hierarchy of electoral districts, from congressional districts down to local precincts; at the congressional level they are numbered by state, and at the very local level they are I think numbered by town or county. It seems like it would be useful to have some sort of specialized property to identify these numbers with geographic locations (particularly now we can map them with the geoshape datatype!) but I suppose catalog code (P528) could do in a pinch. See en:Lists of electoral districts by nation for some differences between countries on this. ArthurPSmith (talk) 17:43, 31 March 2017 (UTC)
  • Symbol support vote.svg Support I support the proposal as it is at present. SJK (talk) 10:31, 5 April 2017 (UTC)

related to (see also)[edit]

Consider item: Ajoure (Q4699945) metal decorating technique similar to filigree

  • I added: different from (P1889) - Ajouré (Q4058082) decorative textile technique
  • Now I want to add: related to - Filigree (Q1001313) delicate kind of jewellery metalwork

I'm surprised that I can't find an appropriate prop.

  • relation (P2309) is only for property constraints, and the example at Property_talk:P2309 is not any good: "relation ==> Instance (Qxyz)")
  • see also (P1659) is only for properties. I suggest to change it to apply to any item. Do you agree? If not, I'll make a proper prop proposal.

--Vladimir Alexiev (talk) 13:23, 22 April 2017 (UTC)

Symbol oppose vote.svg Oppose having miscellaneous "related to" relationships, as they are not structured data. Such proposals have been rejected several times in the past. --Yair rand (talk) 00:17, 28 April 2017 (UTC)
@Yair rand: So you don't find it useful to connect ajoure (Q4699945) and Filigree (Q1001313) ?
They should be probably related. But not this way. We should think of the right way to link them. What do they have in common ? They are both subclasses of Jewellry metalworks for example. We should probably be able to express precisely what they have in common using precise properties. Inventing new one if needed. author  TomT0m / talk page 11:43, 20 May 2017 (UTC)
  • In general please follow the usual way of proposing a property with the "property proposal" template. As far as this particular issue goes, if ajoure (Q4699945) and Filigree (Q1001313) are related because they are similar kinds of metalwork there's likely a superclass for that kind of metalwork. I agree with TomT0m and Symbol oppose vote.svg Oppose. ChristianKl (talk) 10:38, 23 May 2017 (UTC)

topic's main Wikimedia outline[edit]

   Under discussion
Description Wikimedia outline associated with this topic
Represents Wikimedia outline article (Q26884324)
Data type Item
Example knowledge (Q9081)Outline of knowledge (Q7112676)

Same motivation as topic's main Wikimedia portal (P1151). This is an important navigational structure within Wikipedia (i.e., en:Wikipedia:Outlines). Outlines have their own WikiProject (i.e., en:Wikipedia:WikiProject_Outlines). We can better classify outline articles in Wikidata as well as support the WikiProject by adding this property. Runner1928 (talk) 16:45, 27 April 2017 (UTC)



   Under discussion
Description Changed (or revised/altered/modified) - Anything that has changed at a given point in time
Data type Point in time
Allowed units Same as start time (P580)
Example Kathmandu Valley (Q970717) -> heritage status (P1435) -> World Heritage Site (Q9259) -> changed -> 2006 (ref)
Planned use UNESCO heritage sites via en:Template:Infobox World Heritage Site/Wikidata, but there are obviously wider applications

Unless I'm mistaken, we don't currently seem to have any way to mark that something was changed/modified/altered/revised on a given date. This would seem like a good generic property to add so that we can mark when this happens. Thanks. Mike Peel (talk) 22:56, 2 May 2017 (UTC)

Pictogram voting question.svg Question For the provided example, wouldn't it work to use ? Josh Baumgartner (talk) 23:29, 2 May 2017 (UTC)
@Joshbaumgartner: The start date in this case is 1979; it was then revised in 2006. So the structure you're saying is already in use for the 1979 value (see Kathmandu Valley (Q970717)), but I can't figure out how to indicate the change in 2006. Thanks. Mike Peel (talk) 14:48, 3 May 2017 (UTC)
@Mike Peel: Got it. From my quick read it was what UNESCO calls a 'Minor Modification' to the boundaries of the site. It sounds like we need some way of capturing what the change was. What about
< Kathmandu Valley (Q970717) View with Reasonator View with SQID > significant event (P793) View with SQID < Minor Modification >
point in time (P585) View with SQID <  2006 >
and referencing the UNESCO docs? It is a little tricky capturing a border change when at the moment we aren't capturing the original or current borders. Josh Baumgartner (talk) 20:57, 3 May 2017 (UTC)
Pictogram voting comment.svg Comment Just to know that something changed on a certain date is not really informative. More interesting is to know what changed when. In case of Kathmandu Valley (Q970717) the size of the area was adapted. This could be modelled as follows:
< Kathmandu Valley (Q970717) View with Reasonator View with SQID > area (P2046) View with SQID < 275, 86 ha >
start time (P580) View with SQID < 1979 >
end time (P582) View with SQID < 2006 >
< Kathmandu Valley (Q970717) View with Reasonator View with SQID > area (P2046) View with SQID < 167,27 ha >
start time (P580) View with SQID < 2006 >
< Kathmandu Valley (Q970717) View with Reasonator View with SQID > significant event (P793) View with SQID < reduction of the property >
point in time (P585) View with SQID < 2006 >
--Pasleim (talk) 18:01, 3 May 2017 (UTC)
@Joshbaumgartner, Pasleim: The logic I was using here was "WHS inscription changed on this date" (which covers the what and the when ;-) ). It seems most natural to place that alongside the start time for that heritage status, as a "change". Defining a new type of significant event would work, but means including that information in a separate property rather than as a qualifier for heritage status (P1435). Defining what exactly has changed could be ... messy. It may not be trivial to say what the change was in all cases, and also there could be cases where the entry covers *both* the WHS part of the site and the wider area, in which case qualifiers of WHS need to be put everywhere... Perhaps @John Cummings (as Wikimedian in Residence at UNESCO) can provide some insight into what could be done here as well. Thanks. Mike Peel (talk) 21:23, 3 May 2017 (UTC)
I've applied a Workaround (Q457174) of , which is now in use in the infobox, but we should try to find a better solution to this! Thanks. Mike Peel (talk) 02:38, 5 May 2017 (UTC)
  • Mike Peel (talkcontribslogs), thanks very much for trying to tackle this, I have tried to think about this before with no luck. I had thought about trying to show it through qualifiers in 'has part' being added or taken away at different dates or even by providing different area maps. I think this issue is likely to appear in many other registers where a member has changed over time. If you think this is the best way of doing that then I trust you are correct :) --John Cummings (talk) 10:53, 8 May 2017 (UTC)


   Under discussion
Description type of primer used by a firearm cartridge
Represents primer (Q7243398)
Data type Item
Template parameter "primer" in en:Template:Infobox firearm cartridge
Domain cartridge (Q37144)
Allowed values centerfire (Q190476) OR rimfire (Q1289462)
Planned use I will implement it into Template:Infobox firearm cartridge (Q6289330) on the Slovenian Wikipedia
Robot and gadget jobs maybe

To have the same data in infoboxes for cartridges across all language Wikipedias. --M11rtinb (talk) 11:24, 7 May 2017 (UTC)

Should probably have a more specific description so that it's clear it's only for firearms cartridges (and not, say, the ignition method on rocket motors). Andrew Gray (talk) 16:46, 7 May 2017 (UTC)
Good point --M11rtinb (talk) 17:02, 7 May 2017 (UTC)
"this parameter would describe" is not a good start for a description. Take a look at a few descriptions of properties and try to put your description in the same form. ChristianKl (talk) 23:12, 12 May 2017 (UTC)

rim type[edit]

   Under discussion
Description this property would describe the type of rim that a firearm cartridge case has
Represents rim (Q128367)
Data type Item
Template parameter "type" in en:Template:Infobox firearm cartridge
Domain cartridge (Q37144)
Allowed values rimless (Q29842379), rimmed (Q29842212), semi-rimmed (Q29842410), rebated (Q29842473), belted (Q29842449), grooveless (Q29842430)
Planned use I will implement it into Template:Infobox firearm cartridge (Q6289330) on the Slovenian Wikipedia

To have the same data in infoboxes for cartridges across all language Wikipedias. --M11rtinb (talk) 11:59, 7 May 2017 (UTC)

I think has quality (P1552) is good enough for this use case. ChristianKl (talk) 12:46, 19 May 2017 (UTC)
Symbol oppose vote.svg Oppose @ChristianKl, M11rtinb: This is a specific typing property. We’re actually discussing types and subtypes of cartridge (Q37144) that should be handled using instance of (P31) and subclass of (P279) (see Help:BMP and Help:Classification). rimless (Q29842379), rimmed (Q29842212), semi-rimmed (Q29842410), rebated (Q29842473), belted (Q29842449), grooveless (Q29842430) are all subclasses of munitions (not instances) To express that munitions can be rimmed, semi-rimmed or rimless, you could use one statement like - this means «a cartridge (Q37144) View with Reasonator View with SQID can be either rimmed, semi rimmed or unrimmed, but nether remmed and unrimmed (or rimmed and semi rimmed or …) . And maybe or depending if a rim can be both or  TomT0m / talk page 12:14, 20 May 2017 (UTC)
I've tried to modify cartridge (Q37144) based on your idea. Please check if it was done correctly. --08:21, 21 May 2017 (UTC)
@TomT0m: But how could this be implemented in a Wikipedia infobox? If a cartridge is both an instance of rifle cartridge (Q7333267) and rimmed (Q29842212), how could I specify that I only want the value that describes the type of rim? --M11rtinb (talk) 18:12, 22 May 2017 (UTC)

emits A under B[edit]

   Under discussion
Description to indicate what is emitted (nothing, toxic gas, ~radioactivity); used as main property
Data type Item
Domain material (Q214609)
Example autoclaved aerated concrete (Q916964) → none
   Under discussion
Description to indicate value when exposed to condition (heat, UV, normal state); used as qualifier
Data type Item
Domain process (Q3249551)
Example none → fire (Q3196)

Similar to organic produced by (P2849), but we don't have a "when" qualifier. d1g (talk) 14:34, 21 May 2017 (UTC)

If you want to propose a solution that takes two properties, please have two property proposal templates. Apart from that there's the question of prior art. Are there other ontologies that model this relationship which we might want to copy? ChristianKl (talk) 11:03, 22 May 2017 (UTC)
Quick search shows no specific properties among public material-related resources.
Should I create a new subpage? d1g (talk) 17:34, 22 May 2017 (UTC)
You can do it in the same subpage is you wish or create a new one. Both works. ChristianKl (talk) 19:03, 24 May 2017 (UTC)
  • The second property certainly needs a name. The first one should explain in the description how it relates to the second one. ChristianKl (talk) 15:40, 16 June 2017 (UTC)

panorama view[edit]

   Under discussion
Description Panorama view of the object.
Data type Commons media file
Domain any
Allowed values Commons media with corresponding images
Example no label (Q10501350)File:Förkärla_kyrka_20160421_06.jpg
See also nighttime view (P3451)

There is plenty of panorama views available on Commons and a property in addition to image (P18) would assure that the data in Wikidata is as structured as possible. Abbe98 (talk) 16:38, 28 March 2017 (UTC)


exists between[edit]

   Under discussion
Description subject item exists between object item(s) physically
Data type Item
Example Shoulder joint (Q1758798)values as qualifiers (Q23766486) (of (P642): scapula (Q16336) & humerus (Q162595))
oval window (Q2301793)values as qualifiers (Q23766486) (of (P642): middle ear (Q501553) & scala vestibuli (Q617973))
synaptic cleft (Q15320191)values as qualifiers (Q23766486) (of (P642): presynaptic membrane (Q14864381) & postsynaptic membrane (Q14864257))
palate (Q172605)values as qualifiers (Q23766486) (of (P642): cavity of mouth (Q27042858) & nasal cavity (Q156104))
Core–mantle boundary (Q1330051)values as qualifiers (Q23766486) (of (P642): Planetary core (Q742129) & mantle (Q101949))
equator (Q23538)values as qualifiers (Q23766486) (of (P642): Northern Hemisphere (Q39061) & Southern Hemisphere (Q41228))

This property is useful to describe some anatomical relations (see above examples). And it mey be able to use for general uses.

Doc James
Daniel Mietchen
Andrew Su
Projekt ANA
Pavel Dušek
Was a bee
Chris Mungall
Pictogram voting comment.svg Notified participants of WikiProject Medicine --Okkn (talk) 06:32, 23 May 2017 (UTC)

  • Why do you think this property will be better than using connects with (P2789)? ChristianKl (talk) 08:47, 23 May 2017 (UTC)
  • I do not know I want to say yes because it is easy to find examples where this is the best way to describe the relationship between things. I want to say no because this is so vague that it would be hard to describe when to use this and when the relationship is trivial to note. Perhaps if the name could be made more specific then using it would be more meaningful. Like for example, should every street be tagged like Seventh Avenue (Q109926) -> exists between Sixth Avenue (Q109873) and Eighth Avenue (Q109951)? This seems like an inefficient way to sort maps, even if the relationship might work for body parts. Blue Rasberry (talk) 14:02, 23 May 2017 (UTC)
@ChristianKl, Bluerasberry: In case both connects with (P2789) and «exists between» can be used, connects with (P2789) should be used. (ex. NOT “stomach «exists between» esophagus and small intestine” but “stomach «connects with» esophagus and small intestine”)
However, some relations such as the above examples is a little different from connects with (P2789) because the subject item and object items are heterogeneous. In my opinion, boundary surface doesn't connect with its surrounding object. This is the same with bone vs joint or cavity vs wall relationships. In addition, if X «exists between» A and B, X usually can't be exist without the existence of A and B.
I feel certain that this property is required. --Okkn (talk) 14:56, 23 May 2017 (UTC)
@Okkn: Okay, that seems reasonable. I am not sure what more I should ask. Would it be fair for me to ask that you write some documentation which says, "If both this and property X can be used, then use only property X, which is more specific"? I do not know how properties get documented here, but it seems like there would be standard text for saying how users should apply the most specific property which could be applied when both a specific one and a vague one are available. Blue Rasberry (talk) 15:05, 23 May 2017 (UTC)
@Bluerasberry: I agree with you. Maybe description field or Wikidata usage instructions (P2559) statement is the place for that use.
And I think that constraints like {{Constraint:Conflicts with|list={{P|2789}} }} or those for other specific properies can be used. --Okkn (talk) 16:11, 23 May 2017 (UTC)
There's another issue, our properties takes one value and not two. When it takes more than one value we usually use qualifiers. ChristianKl (talk) 15:40, 23 May 2017 (UTC)
@ChristianKl: If there is only just one pair of two values, can't it be dealed with in the same manner as connects with (P2789)?--Okkn (talk) 16:11, 23 May 2017 (UTC)
@Okkn: The semantics of our properties are structured in a form that they work even if there's more than one pair of values. ChristianKl (talk) 17:11, 23 May 2017 (UTC)
@ChristianKl: I think this property should have only just one pair of values. Is that still no good? --Okkn (talk) 17:35, 23 May 2017 (UTC)
Unfortunately, no. The semantics of the property shouldn't change when another pair of values gets added. There's also no natural way to determine which is the one-and-only correct value that's between A and B and our usual way to deal with a case where there isn't an absolute truth is to allow different people to make different statements. ChristianKl (talk) 10:26, 24 May 2017 (UTC)
@ChristianKl: OK. Then, whould it be a problem if we use values as qualifiers (Q23766486) and of (P642) to take a pair of values? (I fixed the above examples.) --Okkn (talk) 15:30, 24 May 2017 (UTC)
I'm okay with those semantics. ChristianKl (talk) 15:41, 24 May 2017 (UTC)

surrounds or encloses/surrounded or enclosed by[edit]

   Under discussion
Description something that is physically surrounded by the subject item
Data type Item
Example Endomysium (Q3395843)muscle fiber (Q18891564) = myocyte (Q428914)
Perimysium (Q3543470)Muscle fascicle (Q6321987)
fascia (Q936531)skeletal striated muscle (Q1048687)
bony labyrinth (Q262489)membranous labyrinth (Q6593307)
Myelin (Q187388)axon (Q178999)
Amnion (Q473749)embryo (Q33196) and amniotic fluid (Q901674)
atmosphere of Earth (Q3230)Earth (Q2)
mantle (Q101949)Planetary core (Q742129)
   Under discussion
Description something that surrounds the subject item
Data type Item
Example muscle fiber (Q18891564) = myocyte (Q428914)Endomysium (Q3395843)
Muscle fascicle (Q6321987)Perimysium (Q3543470)
skeletal striated muscle (Q1048687)fascia (Q936531)
membranous labyrinth (Q6593307)bony labyrinth (Q262489)
axon (Q178999)Myelin (Q187388)
embryo (Q33196)Amnion (Q473749) and amniotic fluid (Q901674)
Earth (Q2)atmosphere of Earth (Q3230)
Planetary core (Q742129)mantle (Q101949)

This property is useful to describe some anatomical relations (see above examples). And it mey be able to use for general uses.

Doc James
Daniel Mietchen
Andrew Su
Projekt ANA
Pavel Dušek
Was a bee
Chris Mungall
Pictogram voting comment.svg Notified participants of WikiProject Medicine --Okkn (talk) 07:15, 23 May 2017 (UTC)

  • I do not know I think it would be excessive to have this apply to maps. Like for example, many statues are "surrounded" by parks. Would all monuments in all parks use this? What limits should be on this property? Blue Rasberry (talk) 15:01, 23 May 2017 (UTC)
  • I don't feel strongly about the issue of marks and monuments. ChristianKl (talk) 11:50, 24 May 2017 (UTC)


   Under discussion
Data type String
Template parameter
Allowed values ???
Allowed units ???
Arcade and video games
See also Wikidata:Property proposal/Archive/16#video display resolution

Very surprised this hasn't be added. We probably need a new datatype. Many cellphone databases exist with this information. We need to figure out Display size, character displays (e.g. Data Discman (Q5227158) → 30 characters by 10 lines, each character 8x16 pixels), handling weird screens (e.g. the sub-pixel configuration RGB/RBG Horizontal/Vertical, PenTile display, w:OLPC XO's switchable display, w:Beam-index tube, w:Autostereoscopy display, barrel-distorted HMDs) Dispenser (talk) 21:31, 23 May 2017 (UTC)

  • I see the value if being able to capture this information in Wikidata but the proposed way to use strings seems a bit ugly. Mixing × with x is calling for problems. I think I prefer a solution with has part (P527) display which is qualified with three separate qualifiers for height (P2048), width (P2049) and resolution. ChristianKl (talk) 11:57, 24 May 2017 (UTC)
  • Symbol oppose vote.svg Oppose per ChristianKl. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:12, 28 May 2017 (UTC)
  • Symbol oppose vote.svg Oppose with this particular name and implementation as per above commenters, though the idea of recording resolution is valid and useful. Suggest that it use an existing property, and then the appropriate horizontal, vertical and bit-depth properties are integers that can be properly queried. - Fuzheado (talk) 15:11, 30 May 2017 (UTC)

language-independence of instances[edit]

   Under discussion
Description this property specifies, whether instances of this class usually have the same label in different languages
Data type Item
Example human (Q5)same label in all languages with a Latin alphabet (Q30051102)

We have currently bots like Edoderoobot that copy for humans the English name to Dutch. Currently, the knowledge about what the logic of what labels should be copied is completely stored within the code of the bot where only the bot operator can influence it. I think it would make more sense to store the logic directly in Wikidata.

I'm not sure that this proposal is the best way to model the domain and I welcome suggestion to improve the modelling. ChristianKl (talk) 17:22, 25 May 2017 (UTC)

  • This seems out of place as a property proposal. There is a number of types of labels that should (default) be the same for all languages: scientific names of organisms, books, movies, songs, etc. What would really make sense is to have the software produce these labels whenever somebody calls up the item. That is, not to fill in labels in any language, but produce a label at need. This would save lots and lots of edits and a lot of storage space [by the way "human" is an item with different lables in different languages]. - Brya (talk) 18:13, 25 May 2017 (UTC)
I'm against automatic management of labels and descriptions. With an automatic tool we lost the power of the constraints on Label+Description. --ValterVB (talk) 11:01, 26 May 2017 (UTC)
  • I don't like properties which simplify a complex task to a single statement. It's not true that all people have the same name in languages with Latin alphabet. There are many exceptions, e.g. cyrillic translitarated names (Andrei Tarkovsky (Q853)), names of historical people (Plato (Q859)) or other translatable names (Elizabeth II (Q9682)). Bot operators should do such considerations when writing a new script and not just rely on a statement. --Pasleim (talk) 16:51, 26 May 2017 (UTC)
    • If rules can be defined that would be fine, but I agree that the sample above can't work out.
      --- Jura 09:32, 27 May 2017 (UTC)
    • Plus some languages using the Latin script routinely alter names which are already in Latin script (there's a bunch of examples in the Latin labels of Albert Einstein (Q937) and Barack Obama (Q76)). - Nikki (talk) 19:00, 30 May 2017 (UTC)
  • Previous discussions, among others, are Wikidata:Bot requests#Taxon labels, and in the Project Chat archives for November 2016 and March 2017. I note that we still have a bot adding labels for taxon items in some languages, but not others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:09, 28 May 2017 (UTC)
  • @ChristianKl: I assume you meant "instances of this class" rather than "instances of this property" in the description? I'm wondering if a better approach might be to create a property for languages that gives a prioritized list of other languages to fall back on for labels? If only one label is needed (in the instances such as Brya cites) then copying labels wouldn't be necessary if there was a good display solution. ArthurPSmith (talk) 18:31, 30 May 2017 (UTC)
    • @ArthurPSmith: You are right, I changed it accordingly. I like your suggestion of describing the ideal fallback. ChristianKl (talk) 18:39, 30 May 2017 (UTC)
    • I don't think adding a property for that would help: MediaWiki already has language fallback chains, which Wikidata already uses (see commons:File:MediaWiki_fallback_chains.svg, you can see what it is for you at Special:MyLanguageFallbackChain and there is a ticket at phab:T89213 for allowing fallback to any language). That functionality is completely independent of Wikidata and it seems unlikely to me that the developers would want to add a second way to do the same thing. - Nikki (talk) 19:26, 30 May 2017 (UTC)
      • well I'd suggest that fallback chain in MediaWiki is broken in several ways. For me it lists Russian (cyrillic) as one of the languages - which I can read somewhat laboriously, but if a label is given in, say, Dutch or Polish which are not on my language list, and there's a Russian label as well, I'm going to see the Russian when I'd much rather see the native Dutch or Polish label. I think defining this better with wikidata would be a useful thing for everybody. ArthurPSmith (talk) 19:03, 31 May 2017 (UTC)
  • I'm currently opposed to this proposal because it's not as simple as this (as pointed out above, even the example you gave is not true). I think there needs to be more discussion about when it is suitable to copy a label before we can decide on which properties we would need. I would definitely welcome such discussion - people seem to like to blindly copy the same label to every language without knowing which ones it's appropriate to copy it to and it's really difficult to clean up. - Nikki (talk) 19:00, 30 May 2017 (UTC)

Wikidata complete SPARQL query equivalent[edit]

   Under discussion
Description SPARQL code that returns a set of items
Data type String
Domain Wikimedia list article (Q13406463) or other kind of list
Example city (Q515) View with Reasonator View with SQID SELECT DISTINCT ?item WHERE { ?item wdt:P31/wdt:P279* wd:Q515 }
See also Wikidata SPARQL query equivalent (P3921)
a query that need more complex criterium

Wikidata SPARQL query equivalent (P3921) don't permit to create more complex query, With this property we can add more complex query (UNION, subquery, etc) to list item. ValterVB (talk) 20:05, 31 May 2017 (UTC)

@ValterVB: Please provide a proper, full, example, and the item to which it elates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:35, 1 June 2017 (UTC)
Symbol support vote.svg Support SELECT DISTINCT is something needed for some items. d1g (talk) 12:59, 6 June 2017 (UTC)

number of strokes[edit]

   Under discussion
Description quantity of strokes used to write the character
Represents stroke (Q1689024)
Data type Quantity
Template parameter | NbTraits = in fr:template:Infobox Idéogramme
Domain CJKV characters, maybe other writing systems too

Not entirely sure if 'string' or 'number' is best here. ~nmaia d 02:47, 9 June 2017 (UTC)

GA candidate.svg Weak support this might also be accomplished with has parts of the class (P2670) with value stroke (Q1689024) and a quantity (P1114) qualifier. ArthurPSmith (talk) 18:27, 9 June 2017 (UTC)

Search formatter URL[edit]

   Under discussion
Description Web page search URL; URI template from which "$1" can be automatically replaced with the sting to be searched for
Data type String
Domain websites & web services; Wikidata external ID properties
Allowed values Search URLs, with "$1" replacing the search string
See also formatter URL (P1630), URI used in RDF (P1921), third-party formatter URL (P3303)

We should be able to programmatically indicate how to use a website's search facility; not least for external IDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:04, 15 June 2017 (UTC)

  • Pictogram voting comment.svg Comment What is suppose to run into $1? The label? If, yes. Which language? — Finn Årup Nielsen (fnielsen) (talk) 20:17, 15 June 2017 (UTC)
    • @Fnielsen: Whatever anyone wants to search the target site for. In the specific Scholia search which we discussed elsewhere, yes, you could use ?authorLabel. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 16 June 2017 (UTC)
  • Symbol support vote.svg Support, though what happens for those search facilities that expect more than a simple search string? Mahir256 (talk) 21:17, 19 June 2017 (UTC)
@Pigsonthewing: I will admit I don't have a ready example of this, but a lot of search pages for catalogues require a specific class of result to be returned (whether authors, books, publishers, or the like) that is typically specified within the URL. Should a separate URL be needed under this proposal for each type of search result? Mahir256 (talk) 18:51, 21 June 2017 (UTC)

contact point[edit]

   Under discussion
Description entity serving as focal point of information
Data type Item
Domain any
Allowed values items that are subclasses of contact point (Q30322502)
Example historical monuments in the city of Zurich, Switzerland (Q30237745) → new item as instance of instance of (P31) contact point (Q30322502) (probably with qualifier subject has role (P2868)
See also

Property to reference items serving as a focal point - for example, a Customer Complaints department. Can be used in different domains. As a contact point of an organization, of a public institution such as a museum or (as intended) as a contact point (and supplier) of a dataset (see sample). Andheb (talk) 22:07, 17 June 2017 (UTC)



   Under discussion
Description small-sized datum derived from a block of digital data for the purpose of detecting errors
Data type String
Domain any
Allowed values any
Example distribution of historical monuments in the city of Zurich, Switzerland, June 2017 (zip) (Q30243079) → 23908402390
Planned use use it to add a checksum to distributions of data sets

Checksums are used in different domains for the purpose of detecting errors. Examples are digital distributions, software downloads and furthermore. Andheb (talk) 22:24, 17 June 2017 (UTC)

Symbol support vote.svg Support - however it should be used with a qualifier specifying the checksum method (eg. MD5 (Q185235)). ArthurPSmith (talk) 20:04, 19 June 2017 (UTC)
  • Symbol support vote.svg Support. This property will be very helpful for modeling checksums. I agree with ArthurPSmith's suggestion about a qualifier describing the checksum method. YULdigitalpreservation (talk) 17:06, 21 June 2017 (UTC)


   Under discussion
Description unique version name or number to a unique state of an entity
Data type String
Domain any
Allowed values valid name or number of a version
Example historical monuments in the city of Zurich, Switzerland (Q30237745) → 1.0
Planned use Version number for a data set distribution (see example)
See also software version (P348), ,

Neutral property for version as suggested in property proposal for unstable version (not done). There is already a property software version (P348) specific for software. Another not done version proposal was kernel version. The neutral version property can be used in different domains as for document version or versions of digital distributions. Suggested alias: revision. Andheb (talk) 22:47, 17 June 2017 (UTC)

Hmm, I think for datasets we are using edition number (P393) which seems sufficient (despite the label it will take anything for the 'version string' value, it doesn't have to be numeric) and has an alias 'version number'. So I don't think a new property is needed here, use edition number (P393). ArthurPSmith (talk) 20:01, 19 June 2017 (UTC)

Category of software programmed with this programming language[edit]

   Under discussion
Description Wikimedia category for software programmed with this programming language
Data type Item
Domain Wikimedia category (Q4167836)
Example PHP (Q59)Category:PHP software (Q9096249)
Source Wikipedia categorization
Planned use simplify the w:it:Modulo:Software/Configurazione

We can use it to simplify software categorization. Valerio Bozzolan (talk) 10:20, 23 June 2017 (UTC)