# Wikidata:Property proposal/Generic

 Before proposing a property Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties. Check if the property was previously proposed or is on the pending list. 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. Select the right datatype for the property. Start writing the documentation based on the preload form below and add it in the appropriate section.Creating the property Once consensus is reached, change status=ready on the template, to attract the attention of a property creator. Creation can be done 1 week after the proposal, by a property creator or an administrator. See steps when creating properties.
 On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2019/08.

## General

### located in the constituency

Under discussion
Description place which is located in a constituency or electoral district constituency (Q192611) Item location (Q17334923) Sarbari (Q60292834) → Bankura Lok Sabha constituency (Q4856799) Sarbari (Q60292834) → Raghunathpur Vidhan Sabha constituency (Q7283039) Raghunathpur (Q3929423) → Raghunathpur Vidhan Sabha constituency (Q7283039) school district (P5353), located in the ecclesiastical territorial entity (P5607)

#### Motivation

This property will describe a place which is located in a certain constituency or electoral district. Bodhisattwa (talk) 05:37, 4 March 2019 (UTC)

Sample electoral districts. --- Jura 10:57, 10 March 2019 (UTC)

#### Discussion

• A prior property proposal is at Wikidata:Property proposal/District. @Mdmahir: as proposer, @Jura1: as supporter of that proposal, and @Pigsonthewing, ChristianKl, Pasleim, ArthurPSmith, Yair rand: as opponents of that proposal. Mahir256 (talk) 06:08, 4 March 2019 (UTC)
•   Comment The relationship between administrative divisions and electoral divisions has been neglected for some time, and most certainly deserves some way of being modeled here on Wikidata. I do think that rather than completely supporting or completely opposing this proposal, changes to this proposal such that the result can handle different political situations will be necessary. To those of you I named above who opposed it, for example, help us handle the situation of countries in which gerrymandering prevails (like in Five Eyes countries). To those of you who support this proposal as written, for example, help us handle the situation of countries in which constituency delimitations follow existing administrative boundaries somewhat well (like in India and Bangladesh). Mahir256 (talk) 06:08, 4 March 2019 (UTC)
• Intuitively, I would prefer a property that's more general and can be also used for census districts as well as electoral districts.

Notified participants of WikiProject every politician ChristianKl❫ 08:32, 4 March 2019 (UTC)

•   Support Good idea, located in the administrative territorial entity (P131) is not appropriate place for constituencies.--Jklamo (talk) 10:10, 4 March 2019 (UTC)
•   Support Yes. depending on electoral law per country it can or cannot have the same boundaries as administrative regions Masti (talk) 10:57, 4 March 2019 (UTC)
•   Oppose (as currently written, though I'm supportive of the larger idea). Allocating every city, town, village etc to specific electoral districts (as well as to an administrative district) doesn't seem either sensible, or particularly useful. The example given above, of Sarbari (Q60292834) being in both Bankura Lok Sabha constituency (Q4856799) and Raghunathpur Vidhan Sabha constituency (Q7283039) doesn't seem like the best way of being able to say that. I agree that we definitely need a good way of relating electoral districts and administrative districts, but this doesn't seem to be it.
• More generally, there are four scenarios that we generally need to cover here, for each type of electoral district (and, of course, most places are in multiple different electoral districts simultaneously as they elect people to multiple different bodies: e.g. a city council, county council, state legislature, national legislature, and supranational legislature (some which which can separate constituencies for lower houses vs upper houses). These certainly can neatly nest within each other in some places, but my experience is that that's the exception, rather than the norm.)
1. Where electoral districts have a one-to-one match to administrative districts (e.g. the US, or Australia, where the constituencies of the Senate are the States).
2. Where electoral districts neatly contain one or more administrative districts, e.g. in Finland the constituencies of the Eduskunta mostly match the regions of Finland, other than a couple that combine multiple, e.g. South-Eastern Finland (Q18691231) which is made up of South Karelia (Q5691), Southern Savonia (Q5693), and Kymenlaakso (Q5698)
3. Where an administrative areas neatly contain multiple electoral districts: e.g. each Canadian state contains one, or more than one, Senate division. However, it also often useful to break things down to a higher level of precision, e.g. to say that each the city of Bristol (Q23154) is represented in the UK Parliament by Bristol West (Q1072698), Bristol East (Q1070148), Bristol South (Q578636), and Bristol North West (Q3137955)
4. Where there is essentially no mapping from an electoral district to an administrative district, other than it being within something at a larger scale (e.g. some of the common examples of heavily gerrymandered districts, or places with complex borders, such as Baarle-Nassau (Q9811), Baarle-Hertog (Q244959), where some of the electoral difficulties are described at http://news.bbc.co.uk/1/hi/world/europe/8027086.stm)
• A key issue is also that, even when dealing only a single "type" of constituency (and quite a few legislatures explicitly have multiple types) it is not always possible to map all the electoral districts in a given jurisdiction using only one of these methods. This can then make it very difficult to know how to formulate queries to get useful/relevant information back out again, even where you have good knowledge of the underlying structure of that jurisdiction+elected body, and close to impossible if you don't. --Oravrattas (talk) 11:24, 4 March 2019 (UTC)
• Thinking about this some more, I believe the best way to model this is to provide electoral district maps (i.e. in Commons I guess) for each district, and then you can in principle retrieve relevant districts for any location via those maps. But that doesn't make retrieval of relevant districts for a location easy from the query angle, so it would be helpful to have a secondary (derived) relation that represents the relationship of locations to districts. However, "in" is the wrong word for this, because there are far too many cases (even in the US) where one type of location is not wholly contained within the other type in either direction. So I think a looser secondary "related district" or "overlaps with geographic object" or something like that would be the right sort of property for this. ArthurPSmith (talk) 14:00, 4 March 2019 (UTC)
@ArthurPSmith: See territory overlaps (P3179). I don't like the increasing number of "located in area of type X" properties. Plenty of countries have many types of regional divisions, some of which aren't administrative territorial entities. Should there be a property for every type? Something else to consider: Is Mexico (Q96) located in the constituency Second constituency for French residents overseas (Q3025246)? --Yair rand (talk) 04:03, 5 March 2019 (UTC)
Ok,   Oppose this one - use territory overlaps (P3179)! ArthurPSmith (talk) 14:39, 5 March 2019 (UTC)
Not only for France. Legally, every place outside Poland is in Warsaw (Q270)'s district, so it had to be added to every place and every ship (with a Polish citizen onboard). Panek (talk) 11:19, 15 August 2019 (UTC)
•   Oppose Whilst I agree that "located in the administrative territorial entity" is not the ideal property to use to explain the hierarchy of electoral districts, as this stands it seems far too prone to confusing usage. I think @ArthurPSmith: pretty much sums up my concerns, and that the correct solution is to both add spatial data to the Commons (for those who know how to query it, and this is good practice anyway for anything with a boundary) and to be able to say "related to district" for expressing more concrete terms such as "this district is explicitly defined as being a part of this district" and vice-versa. --jacksonj04 (talk) 09:35, 6 March 2019 (UTC)
•   Support I don't really see another working solution. P131 might seem to be working for countries where they more or less fit between existing administrative layers, but even there it tends to lead to the mistaken assumption that electoral districts actually are administrative layers. --- Jura 10:57, 10 March 2019 (UTC)
•   Oppose To prone to gerrymandering (Q476310), i.e. changes very often. In many countires too often to be udated at time. Panek (talk) 11:19, 15 August 2019 (UTC)

Under discussion
Description Arcade system hardware board the system motherboard used by a hardware device computer hardware (Q3966) Item `|placa base=` and `|sistema arcade=` in Ficha de hardware and Ficha de videojuego property Almost inmediately, to be used in (Arcade) videogames infobox

#### Motivation

I want to create this as a series of properties to be used in Videogames infoboxes. This would be an alias for "Motherboard" instead. Namely, this is intended for the motherboard codename, specially in arcade machines, wich several ones uses the same motherboard. Amitie 10g (talk) 22:01, 1 April 2019 (UTC)

Notified participants of WikiProject Video games --Jean-Fred (talk) 17:04, 8 April 2019 (UTC)

#### Discussion

Comment Can you fix the examples? NMaia (talk) 01:12, 2 April 2019 (UTC)

I've added the proposed value. Is this a right value for items already existing in Wikidata (ej. the motherboard used in an arcade system)?
If I understand correctly, you would like to express ?
If so, I have been wondering − shouldn’t we just use ? This is already used in the wild:
```SELECT ?item ?itemLabel ?platform ?platformLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?item wdt:P31 wd:Q7889.       # All video games...
?item wdt:P400 ?platform.     # ...whose platform...
?platform wdt:P31 wd:Q631229. # is an arcade system board.
}
```
Jean-Fred (talk) 17:15, 8 April 2019 (UTC)

Oppose Agree that platform (P400) could be used instead. Thadguidry (talk) 22:33, 8 April 2019 (UTC)

• platform (P400) refers to the platform in general (Arcade, Nintendo 64, etc, wich is used already), while "Arcade system" refers to the details of the hardware (generic or codename of the motherboard). arcade system board (Q631229) is a statement, not a property, what we need for the infobox. "Hardware" could be also a name for this property. --Amitie 10g (talk) 15:44, 9 April 2019 (UTC)
Well, at some level we get to decide what platform (P400) means :). You could argue the same way for console and PC games, that we should do something like:
• The layout of the downstream infobox which will use the data is somewhat irrelevant: as far as I know, there is no need for 1-1 mapping between infobox fields and Wikidata statements − I think the infobox could be coded either way in the Lua.
(Not entirely sure what you mean by « arcade system board (Q631229) is a statement, not a property » − based on the definitions used here, it’s neither ;-))
Jean-Fred (talk) 08:51, 12 April 2019 (UTC)
Thanks for fixing the example ; however one question: we can’t model free-text like « Proprietary MIPS based hardware system ». In this case, would it make sense to create an item for that particular hardware? Jean-Fred (talk) 08:52, 12 April 2019 (UTC)
Well, as no way to create free text, I'll take care to create new elements for missing ones, as you mentioned (see the examples above, I fixed them). --Amitie 10g (talk) 12:12, 12 April 2019 (UTC)
•   Support -- 22:39, 14 April 2019 (UTC)
•   Support Sir Lothar (talk) 10:20, 23 April 2019 (UTC)
•   Support.--Vulphere 02:41, 28 May 2019 (UTC)
•   Comment Would it not make more sense to have a more generic "hardware" property and then use a qualifier to specify if it is the motherboard or another piece of hardware? --SilentSpike (talk) 20:20, 7 July 2019 (UTC)
• @Jean-Frédéric: what do you think about SilentSpike's suggestion above? − Pintoch (talk) 21:13, 23 July 2019 (UTC) (fix ping) − Pintoch (talk) 21:14, 23 July 2019 (UTC)

### audio system

Under discussion
Description audio system hardware computer hardware (Q3966) Item `|audio=` in Ficha de hardware and Ficha de videojuego property Almost inmediately, to be used in (Arcade) videogames infobox

#### Motivation

Part of my series for requesting properties for Videogame and hardware infoboxes, namely the audio system for consoles and arcades. --Amitie 10g (talk) 23:50, 1 April 2019 (UTC)

Notified participants of WikiProject Video games --Jean-Fred (talk) 17:06, 8 April 2019 (UTC)

#### Discussion

• Yep, most of the early Atari machines (arcades and home consoles) used the POKEY audio chipset. Please be aware the older pinballs like Gottlieb's "Central Park" used "bells" as their "audio system", therefore, this property is not limited to electronics. --Amitie 10g (talk) 15:53, 9 April 2019 (UTC)
Ok, thanks for the explanation. Some additional questions:
• Would you mind giving additional/different examples with different values?
• I see in es:Quantum_(videojuego) that the value is “POKEYx2” ; how would should we model this « x2 »?
• I see that Star Wars (Q54317) has: « 4x Atari POKEY (música y efectos sonoros), Texas Instruments TMS5220 (síntesis de voz) ». How should we model that?
• Digging around on en.wp for more examples: 3-D Thunder Ceptor II (Q17042246) has « 1x Yamaha YM2151 @ 3.57958 MHz, 1x Namco CUS30 @ 96 kHz, 1x DAC » − how should we model that?
Sorry for asking all these questions − I’m not that knowledgeable about arcade game machines/systems and I’m trying to understand the use case better :)
Jean-Fred (talk) 09:01, 12 April 2019 (UTC)

Ok, been thinking about the Star Wars (Q54317) use case ; would that work?

P<audio system>
POKEY   edit
 quantity 4
 object has role music
 object has role sound effect
▼ 0 reference
TMS5220   edit
 quantity 1
 object has role speech synthesis
▼ 0 reference

(Not sure whether object has role (P3831) is best here, or whether use (P366) would be better…)

Hope that helps :) Jean-Fred (talk) 09:19, 12 April 2019 (UTC)

• The "Sound system" property can have more than 1 value, and the template will reflect that correctly. However, I'm finding ways to add a multiplier value if more than a one unit of a specific chip (eg. POKEY x2) has, in the template (reflecting the "number" parameter given above. --Amitie 10g (talk) 12:17, 12 April 2019 (UTC)
•   Support -- 05:26, 15 April 2019 (UTC)
•   Support Sir Lothar (talk) 10:21, 23 April 2019 (UTC)
•   Support--Arbnos (talk) 14:43, 24 April 2019 (UTC)
•   Support.--Vulphere 02:05, 28 May 2019 (UTC)

Notified participants of WikiProject Informatics ChristianKl❫ 13:49, 17 July 2019 (UTC)

### WMF short URL

Under discussion
Description slug of a short URL for a web page, from the official Wikimedia URL Shortener External identifier pages on WMF projects `[3-9A-HJ-NP-Za-km-z\$][2-9A-HJ-NP-Za-km-z\$]*` Wikidata (Q2013) → d Wikipedia (Q52) → w Wikisource (Q263) → s Arabic Wikipedia (Q199700) → HU French Wikisource (Q15156541) → Yj https://w.wiki/\$1 Wikidata:URLShortener

#### Motivation

The official WMF URL shortener is due to launch on 11 April. The format of the URL is w.wiki/ followed by a string of letters and numbers. The examples shown above have been pre-populated, but longer URL slugs will be generated once the system is available to all editors.

Would this be better as an external-ID type property, with a formatter URL of `https://w.wiki/\$1`? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 3 April 2019 (UTC)

Note: consensus seems to be tending towards an external-id datatype; I've modified the proposal accordingly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 4 April 2019 (UTC)

#### Discussion

•   Support as an external ID so long as there is only one possible short URL domain (w.wiki) that the WMF provides. Mahir256 (talk) 15:42, 3 April 2019 (UTC)
•   Support --Mehman 97 16:08, 3 April 2019 (UTC)
•   Support ~ Nahid Talk 16:22, 3 April 2019 (UTC)
•   Support -- Ajraddatz (talk) 18:21, 3 April 2019 (UTC)
•   Support preferably as external ID; do you have a reference on what characters are allowed in the URL's (i.e. no upper-case letters, no '-', _', etc?) ArthurPSmith (talk) 18:55, 3 April 2019 (UTC)
Hmm, the '\$' ID listed on the documentation page already breaks this regex. ArthurPSmith (talk) 18:57, 3 April 2019 (UTC)
That appears to be a one-off, so I'd add a constraint-exception. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:24, 3 April 2019 (UTC)
• How many items for distinct single pages on WMF projects do we have? I feel like this property would only have about 15 uses total... --Yair rand (talk) 20:54, 3 April 2019 (UTC)
•   Support as external-id NMaia (talk) 02:00, 4 April 2019 (UTC)
•   Support as external-id. ··· 🌸 Rachmat04 · 06:23, 4 April 2019 (UTC)
•   Support David (talk) 07:09, 4 April 2019 (UTC)
•   Support though it seems only stewards will manage the URL themselves.AldNonUcallinme? 13:00, 4 April 2019 (UTC)
• Not so, any editor in good standing (i.e. not blocked on meta) may create a short URL using this service; only stewards may delete them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 5 April 2019 (UTC)
•   Wait Will this be used as a qualifier for links to wikimedia sites? It seems the current proposal doesn't address whether or not that's intended. ChristianKl❫ 07:58, 5 April 2019 (UTC)
•   Support external identifier John Samuel (talk) 18:19, 5 April 2019 (UTC)
• I have to echo the concern of Yair Rand: I don't see enough usage beside few designated shortcuts: rest are randomly created. — regards, Revi 04:57, 6 April 2019 (UTC)
• You don't see "enough usage" because the service is not yet live. As my proposal says, it is due to launch on 11 April. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:58, 6 April 2019 (UTC)
• I don't think we should be storing all the short links for all the wikidata articles, all the wikipedia articles, and then we only have a limited small set of link. That qualifies for "not enough usage", IMO. (In case someone has uncertainty in my comment, interpret my message as firm no.) — regards, Revi 14:45, 13 April 2019 (UTC)
• Where has anyone proposed "storing all the short links for all the wikidata articles [and] , all the wikipedia articles"? Regardless, it has already been established that there will be more then sufficient short URLs ("1000 or more"), relevant to storage in Wikidata, to justify a new property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:51, 13 April 2019 (UTC)
•   Comment seems unclear how this should be used. In general, I think redirecting urls should be avoided. If this property just repeats the interwiki link table (Special:Interwiki), that table might be worth being stored directly. --- Jura 17:25, 7 April 2019 (UTC)
• "In general, I think redirecting urls should be avoided." The Wikidata community; the wider Wikimedia commmunity, and the WMF all seem to disagree with you. To reiterate: The official WMF URL shortener is due to launch on 11 April. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:44, 7 April 2019 (UTC)
•   Oppose   Comment @Pigsonthewing: I support the short URL extension and think it will be useful, but I'm not as sure about the proposed property. As written, the property is to be used on the Wikidata items for the projects/sites which the URLs redirect to, rather than the Wikidata items which describe the same entities as the pages which the URLs redirect to (and I suspect it might end up getting incorrectly used for the latter, including people pointlessly generating short URLs for Wikidata items and then circularly adding those short URLs to the Wikidata items). Almost none of the possible IDs will ever have their own items (e.g. "Alan Turing's English Wikipedia article" probably doesn't need an item), and because the targets are limited to pages within the Wikimedia projects, only notable parts of the Wikimedia movement (e.g. Women in Red) would ever get IDs in the first place. Furthermore, the use of a property for this is sort of pointless given that WMF owns and operates the actual database. It doesn't actually seem to have much utility, other than to advertise that the URL shortener exists. (By the way, The Guardian article ID (P6085) – the only existing property for short URLs – is still nominated for deletion for related reasons.) Jc86035 (talk) 17:02, 8 April 2019 (UTC)
I've struck out the oppose, since a majority of the current short URLs are now redirects to current or possible project home pages. Jc86035 (talk) 17:07, 13 April 2019 (UTC)
•   Comment I agree with those who think this might be confusing, though I'm not withdrawing my "support" vote above as it still seems a useful thing to record within Wikidata. I would note that per Yair rand's question which Andy failed to answer in a reasonable manner, there is a wikidata entry for every language wikipedia (for example Albanian Wikipedia (Q208533)) so that, with the wiktionaries, wikisources, etc. probably adds up to 1000 or more. ArthurPSmith (talk) 18:20, 10 April 2019 (UTC)
• Alert readers will note that I had already addressed that point in my answer of 10:05, 4 April 2019; in the light of which, my subsequent answer was perfectly reasonable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 11 April 2019 (UTC)
• @ChristianKl: I don't understand your comment about waiting. Can you clarify? As I noted just above, the main purpose I see for this property would be to add this property as a statement, for example Albanian Wikipedia (Q208533) with value whatever the shortener ID for "https://hy.wikipedia.org/" is. This seems particularly useful as the shortener works in one direction (from the shortened ID to the wikimedia page) but there's no obvious reverse, so Wikidata could provide that at least for these main pages.
• @Yair rand: You didn't state an opinion for or against here, do you have anything further to comment, given that this should be applicable to 1000+ wikidata items? ArthurPSmith (talk) 19:27, 12 April 2019 (UTC)
• @ArthurPSmith: Wikidata contains plenty of links to Wikimedia websites. It's possible to add a WMF short URL link whenever there is such a link as a qualifier. This discussion till now has had no position on whether adding the property as a qualifier should be allowed. ChristianKl❫ 15:09, 14 April 2019 (UTC)
• I'm going to abstain on the main proposal (I'm unsure about the value of listing shortened URLs in general), but I   Oppose using this instead of or in addition to normal links in qualifiers/references. --Yair rand (talk) 18:23, 14 April 2019 (UTC)
•   Oppose WMF already decided to store this elsewhere, similarly to their other short-url scheme. As stated before, Wikidata doesn't generally store url shorter addresses. Besides, there don't seem to be enough uses for these, unless someone makes them for every item (I doubt that is desirable). --- Jura 06:35, 13 April 2019 (UTC)
• "WMF already decided to store this elsewhere" is, of course, irrelevant to Wikidata - which in any case already has properties for other data which the WMF stores elsewhere. That the quantity of values relevant to our items will be in at least four figures has already been established. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:15, 13 April 2019 (UTC)
• @Pigsonthewing: Pardon, but is your "WMF already decided...irrelevant to Wikidata" meaning that, in one day future, Wikidata should be splitted from WMF (not only we should have separated server clusters, but also build Privacy Policy, Terms of Use, Code of Conduct... ourselves)? --Liuxinyu970226 (talk) 22:08, 27 May 2019 (UTC)
• @Pigsonthewing: I've used a shell script to create most of the possible homepage redirects (1,594, although this includes 653 Incubator, Beta Wikiversity and Multilingual Wikisource projects, other currently non-functioning redirects and various other subdomains). I've put them in a Commons data page so that they can be imported if the property is created. Jc86035 (talk) 17:07, 13 April 2019 (UTC)
•   Comment Some possible issues:
• Which URLs are to be treated as "canonical" (e.g. `https://zh-yue.wikipedia.org/` vs. `http://zh-yue.wikipedia.org/` vs. `https://yue.wikipedia.org/` vs. `https://zh-yue.wikipedia.org` vs. `https://zh-yue.wikipedia.org/wiki/頭版`)? Each of these would be given different redirects by the current version of the software, and at least four variations (5k, 5m, K6 and K7) already exist.
• How will each URL's target be indicated, if that is done? This would be helpful for more easily filtering incorrect or inappropriate values.
• What would start time (P580) indicate as a qualifier? Would it indicate the time that the target became valid, the time that the redirect was created, or either?
Jc86035 (talk) 17:07, 13 April 2019 (UTC)
•   Oppose I do not see the benefit of adding a dedicated property for a URL shortener - shortened URLs are URLs themselves, so why cannot we use our existing URL properties for them? It is not clear to me why URL (P2699) and its sub-properties are not sufficient. I do not think it is useful to indicate a shortened URL in addition to a longer one: by design, they are equivalent and one can easily convert one into the other, so storing both would not be very useful. Also, shortened URLs are not necessarily unique as explained by Jc86035 above - they are not designed to be used as identifiers at all. So, I very much welcome the introduction of the Wikimedia URL shortener, but I do not think this property would be useful. I also note that Pigsonthewing has been very insistently asking admins to create this property and I do not think this is appropriate. @Pigsonthewing: if you are not satisfied with the property creation delays, feel free to give a hand yourself by creating other property proposals marked as ready (there are 47 of them at the moment, so you have plenty of choice). − Pintoch (talk) 12:40, 26 April 2019 (UTC)
•   Oppose Per Pintoch. We already have properties for URLs, I do not see the benefit of adding a dedicated property for a URL shortener, although the URL shortener itself is a great tool.--Jklamo (talk) 17:23, 14 May 2019 (UTC)
• Comment: "shortened URLs are URLs themselves, so why cannot we use our existing URL properties for them?" for the same reason we do not use them for official blog (P1581), archive URL (P1065), or interwiki prefix at Wikimedia (P6720), or any of our identifier properties with a formatter URL. We have ample precedence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 16 May 2019 (UTC)
• Each of the properties you mention have a specific reason to be different from URL (P2699), yes. But invoking that "precedence" does not actually give a reason for this particular property to be separate - could you come up with an argument that is actually related to the proposal? − Pintoch (talk) 12:33, 18 May 2019 (UTC)
•   Support as external-id.--Vulphere 12:31, 27 May 2019 (UTC)
•   Support Non of the oppose reasons are acceptable for me, there has even no BLP concerns, so why not? @Pintoch:? --Liuxinyu970226 (talk) 22:11, 28 June 2019 (UTC)
• I am not sure what you mean? Are we talking about the same proposal? Yes this is not about human beings, so BLP concerns are indeed completely out of scope here. By the way, there is no Bonnie and Clyde problem either. Also, sitelinks for redirects should not conflict with this property. We can list many "problems" like these that are off-topic and therefore not a concern for this proposal. I have given my reasons for oppose above, which one do you want me to elaborate on, if any? − Pintoch (talk) 22:33, 28 June 2019 (UTC)

### cache l1, cache l2, cache l3 and cache l4

Under discussion
Description CPU cache memory CPU cache (Q352090) Quantity `|Cache L1=`, `|Cache L2=` and `|Cache L3=` in Ficha de hardware infobox. processors Core i7-6700 (Q28739510) → "Cache L1" → 256 KB → "Cache L2" → 1 MB → "Cache L3" → 8 MB AMD Ryzen 5 1600 (Q28972980) → "Cache L1" → 384 KB → "Cache L2" → 3 MB → "Cache L3" → 16 MB UltraSPARC III (Q2628825) → "Cache L1" → 64 KB → "Cache L2" → 1 MB Inmediately, for the given infobox

#### Motivación

Part of my infobox improvements. CPU/SoC Cache L1, L2, L3 and L4 are missing in Wikidata and are relevant for CPU-related articles. --Amitie 10g (talk) 23:36, 12 April 2019 (UTC)

#### Discussion

• I'll discusse at Wikipedia how to use qualifies for Lua-based infoboxes. Meanwhile, I'll leave this request opened. --Amitie 10g (talk) 20:46, 13 April 2019 (UTC)
• The proposal has been withdrawn, in part, because the three properties should be requested at once. We have memory capacity (P2928), but once I find ways to add qualifiers to infoboxes, I'll request individual properties instead. --Amitie 10g (talk) 12:42, 14 April 2019 (UTC)
•   Comment You're suggesting three properties here. I wonder if we need three separate discussion pages. John Samuel (talk) 09:24, 14 April 2019 (UTC)
• This, because them represent the same. See my above answers. --Amitie 10g (talk) 12:42, 14 April 2019 (UTC)

Under discussion
Description metadata that the item can store metadata (Q180160) Item many parameters of Template:Infobox file system (Q10777901) file system (Q174989), file format (Q235557), computer program (Q40056) NTFS (Q183205) → access control list (Q338966) (qualifier subject has role (P2868) → filesystem permissions (Q1172314)), 'read-only file' (qualifier subject has role (P2868) → file attribute (Q1144207)), 'archive file' (qualifier subject has role (P2868) → file attribute (Q1144207)), 'system file' (qualifier subject has role (P2868) → file attribute (Q1144207)), 'hidden file' (qualifier subject has role (P2868) → file attribute (Q1144207)) ID3 (Q1054220) → title (Q783521), music interpreter (Q3153559), album (Q482994), year of publication (Q38073102), music genre (Q188451) MISSING to be used in infoboxes always incomplete (Q21873886)

#### Motivación

Organize Wikipedia infoboxes data. -- 05:57, 15 April 2019 (UTC)

#### Discussion

• Can you add some more examples from different domains, or otherwise clarify the intended scope here? ArthurPSmith (talk) 17:21, 15 April 2019 (UTC)
•   Support David (talk) 06:10, 16 April 2019 (UTC)
•   Support ArthurPSmith (talk) 18:01, 16 April 2019 (UTC)
•   Wait From reading the description it's not clear to me what the property does. Is it about metadata stored in the item or metadata stored by the subject that's represented by the item? ChristianKl❫ 13:23, 2 July 2019 (UTC)
• ChristianKl, it is about metadata stored by the subject that's represented by the item. -- 23:17, 5 July 2019 (UTC)
• Telling me what the property is about, does nothing to answer my concern besides suggesting that the current description is unfit. The description of it should be clear enough to be understood by people (and be able to be translated). ChristianKl❫ 07:26, 15 July 2019 (UTC)

Notified participants of WikiProject Informatics Visite fortuitement prolongée (talk) 21:11, 14 August 2019 (UTC)

### expansions of videogame

Under discussion
Description Expansions or DLC for videogames expansion pack (Q209163) Item `|Expansión=` or `|DLC=` in Ficha de videojuego infobox videogames Mario Kart 8 (Q13427106) → "DLC 1" Giana Sisters: Twisted Dreams (Q3762768) → "Rise of the Owlverlord" Inmediately, for the given infobox

#### Motivación

Part of my infobox improvements. This property is intended for expansion packs for such software (mostly videogames), as well as DLC  – The preceding unsigned comment was added by Amitie 10g (talk • contribs).

#### Discussion

•   Support David (talk) 06:28, 17 April 2019 (UTC)
•   Oppose I think the inverse property («expansion of») would be better. -- 07:38, 19 April 2019 (UTC)
•   Comment Whether this is approved or not, it needs a different name - when I saw it on the proposal list I was very confused what it was about. "video game expansion" perhaps, or for the inverse, "expansion of video game"? ArthurPSmith (talk) 18:17, 19 April 2019 (UTC)
• @Amitie 10g: would you consider updating the label per Arthur's suggestion? --- Jura 04:03, 23 April 2019 (UTC)
I've updated the label name. --Amitie 10g (talk) 04:08, 23 April 2019 (UTC)
I think the English name should probably be 'expansion for video game' rather than 'of', and make sure 'expansion' is singular. Nicereddy (talk) 20:30, 1 May 2019 (UTC)
Amitie 10g, I see you've updated the name, but I think the property should be like "DLC 1" "expansion of videogame" Mario Kart 8 (Q13427106). Maybe it would be more difficult using it on infoboxes, but data is better organized. -- 03:51, 3 May 2019 (UTC)
•   Support --Trade (talk) 15:35, 9 May 2019 (UTC)
•   Support Misc (talk) 23:31, 14 May 2019 (UTC)
•   Question Is this intended to be limited to video games or not? --Yair rand (talk) 03:13, 21 May 2019 (UTC)
• As the proporsal says, it is only for videogames software. --Amitie 10g (talk) 21:49, 21 May 2019 (UTC)
•   Support Cwf97 (talk) 15:07, 22 June 2019 (EST)
•   Support With the new name change John Samuel (talk) 09:42, 18 July 2019 (UTC)

Notified participants of WikiProject Informatics ChristianKl❫ 13:48, 17 July 2019 (UTC)

•   Oppose this should be made more general to also allow other types of software. Also I agree with Tinker Bell that the inverse would make more sense. We then could also use it for example for Browser Extensions. -- MichaelSchoenitzer (talk) 21:07, 27 July 2019 (UTC)
•   Comment I cannot imagine how this could work with software? --Trade (talk) 14:56, 4 August 2019 (UTC)

### Shape Expression for class

On hold
Description Shape Expression that members of a class should conform to ShEx (Q29377880) ⧼datatypes-type-EntitySchema⧽ (not available yet) class human (Q5) → E10 film festival (Q220505) → E11 film festival edition (Q27787439) → E12 natural number (Q21199) → E13

#### Motivation

Property to link a class to the Shape Expression that members of it should conform to.

This will make it easier to query for Shape Expressions that exist, and quickly see what has been defined for a particular class. Jheald (talk) 16:56, 28 May 2019 (UTC)

Note: Implementation will require EntitySchema to be added to the set of data-types that can be values for Wikidata statements. There is a ticket for this on Phabricator, which Léa hopes should be resolved in the coming weeks.[1]. Jheald (talk) 07:54, 29 May 2019 (UTC)

#### Discussion

• Proposed. Jheald (talk) 16:56, 28 May 2019 (UTC)
•   Support - PKM (talk) 18:34, 28 May 2019 (UTC)
•   SupportMisterSynergy (talk) 18:43, 28 May 2019 (UTC)
•   Support Dhx1 (talk) 18:44, 28 May 2019 (UTC)
•   Support Finn Årup Nielsen (fnielsen) (talk) 18:52, 28 May 2019 (UTC)
•   Oppose This proposal needs to say much more about how it is supposed to work. Example 1 shows some of the problems. What does "member" mean here? Are only items that are an instance of (P31) to human (Q5) supposed to be covered, or are instances of subclasses (transistive-reflexive closure of subclass of (P279)) also covered? Then there are problems with the shape expression E11 as a shape for humans. The shape requires that the only instance of link for humans goes to human (Q5). The example shape needs to show at least some interesting conditions, such as requiring that children of humans are humans. Example 4 shows more problems. What items are covered here at all? Presumably natural numbers are not items at all, which means that they don't have any outgoing RDF triples. Even if they did, natural numbers should not be instances of instances of natural number. Peter F. Patel-Schneider (talk) 19:46, 28 May 2019 (UTC)
• Interestingness: "The example shape needs to show at least some interesting conditions, such as requiring that children of humans are humans" Yes absolutely, but note that ShEx are only a couple of hours old. I think we will gradually expand it these coming days.
• Members: I do not think this proposal lays any interpretation on the membership and I suppose it would be up to the consensus (or ontology war) whether it should be transitive.
• We have lots of natural numbers, e.g., 42 (Q812996) with outgoing triples. I should say they all should have a numeric value (P1181) which could be check with ShEx.
• Natural number are not "instances of instances of natural number", they are instances of natural numbers.
• A further remark: There are apparent a lack of possibility to keep track of which ShEx are created, e.g., at one point it looked like two ShEx was created for humans. I think a property to keep track of ShEx would benefit the ShEx, helping them to navigate the created schemas, i.e., if you are looking for the ShEx for human you can go to Q5 and follow the link to the ShEx page. — Finn Årup Nielsen (fnielsen) (talk) 20:03, 28 May 2019 (UTC)
• The example is new, agreed, but that only makes the need for good examples higher. If there are no good examples of shapes to attach to classes then there is no reason to have this property. Peter F. Patel-Schneider (talk) 23:50, 28 May 2019 (UTC)
• OK, there are "natural numbers" as items in Wikidata, but the shape says that these are instances of instances of natural number (Q21199), which is not correct. And, yes, there should be a check that their numeric value (P1181) is a natural number (if that is possible in ShEx). Peter F. Patel-Schneider (talk) 23:50, 28 May 2019 (UTC)
• If the scope of a shape connected to a class is to be determined after the fact by the community then I'm completely opposed to this proposal. The scope needs to be nailed down explicitly before this property is allowed. Peter F. Patel-Schneider (talk) 23:50, 28 May 2019 (UTC)
• Thanks for the note about "instance of instance of". This is actual not and "instance of instance of" and I think the way that people used this yesterday should be clarified. I would write the line "p:P31 @<instance-of-statement> ;" and similar the below line. In fact, I have changed the name now. I wonder if that clarify this issue? — Finn Årup Nielsen (fnielsen) (talk) 07:07, 29 May 2019 (UTC)
• I think that there is a clash of philosophies here. Wikidata has been very much ontology-as-you-go with no overall coordination and no enforcing of consistency. We have had property suggestions which guide us to some form of consistency, that may also catch errors and vandalism. ShEx would be a next step. While one could imaging a ShEx-police appearing in Wikidata, that roams about enforcing the one and only scheme upon editors and items, I do not think that is what would be happening. I think that ShExs would be gradually built in an interplay with continuous development and refinement of Wikidata items. For instance, the E34 defines Danish nouns which a ShEx could say should always have a grammatical gender. It appears that proper nouns, plurale tantum and the word druk (L46327) form a problematic set where the grammatical gender might exist and can be set, or it might be unknown or have no value. To resolve this problem one should have an interplay between changes in the Wikidata items and the ShEx. Such problems could be discovered by other means, but I think ShEx would also be a help and steer us into a direction of consistency. — Finn Årup Nielsen (fnielsen) (talk) 09:38, 29 May 2019 (UTC)
•   Support - NavinoEvans (talk) 09:28, 29 May 2019 (UTC)
•   Support - Moebeus (talk) 11:20, 29 May 2019 (UTC)
•   Oppose I'd rather make an item about a shape and link that. --- Jura 09:33, 30 May 2019 (UTC)
• Which advantages do you see in such an approach, compared to this proposal? —MisterSynergy (talk) 09:35, 30 May 2019 (UTC)
• One could describe the shapes in a structured way. Currently, we seem to be getting loads of `#` to do just that. Something we mostly avoided in any other part of Wikidata.--- Jura 09:38, 30 May 2019 (UTC)
• @Jura1: As I understand it, the shapes themselves are meant to describe themselves in a structured, RDF-compliant, queryable way. Isn't that meant to be part of the point of them? Or perhaps that's SHACL (Q29377821) ?? Jheald (talk) 17:23, 30 May 2019 (UTC)
• I'm still learning about the syntax .. maybe it's actually possible. Looking at it's current implementation at Wikidata, maybe we can't do it here, at least not with statements as we would usually do it. If we create a datatype for shapes, supposedly we could have several properties in addition to this one .. one could be "shape expression described in this item", "shape expression associated with list". --- Jura 07:02, 31 May 2019 (UTC)
• @Jura1: Yes. I would hope we wouldn't need "shape expression described in this item", because I hope the shape expression (Exxx) would be its own item, and queryable in its own right. (That would depend on whether a ShEx has an RDF representation that could be included in WDQS -- that would certainly be the case for SHACL; I hope it's true for ShEx). But additional properties like "shape expression associated with list" I would certainly see as likely to be useful. I proposed "Shape Expression for class" first, as it seems likely to be the simplest and most common case, and worth a property in its own right. But there will be shape expressions for things identified other than as members of classes, and we will in turn want ways to point to them. Jheald (talk) 08:55, 31 May 2019 (UTC)
• Two posters on Wikidata-l confirm that there is a standard RDF serialisation of ShEx [2]. So it should be straightforward to load this either into WDQS to describe a shape entity; or into an associated triplestore, that could service federated queries from WDQS. Jheald (talk) 16:46, 2 June 2019 (UTC)
A phabricator ticket is open for this, phab:T225701 Jheald (talk) 09:59, 14 June 2019 (UTC)
• Re "shape expression described in this item": Possibly, but I don't see a plan for that now and there might not be much added value in developing more GUI as it could already be done with Q-entities. --- Jura 10:21, 31 May 2019 (UTC)
• Marking as on hold since the datatype is not available. This is not an assessment of the consensus for / against the proposal. − Pintoch (talk) 20:51, 23 July 2019 (UTC)

### aperture

Under discussion
Description aperture of the camera lens aperture (Q6434802) Quantity en:template:Infobox photographic lens aperture camera lens (Q192234) A range with min and max value or a fixed value as both is possible. Canon EF 800mm lens (Q5033222) → 5.6 Samyang 500mm f/8 (Q25038830) → 8.0 Canon EF 1200mm lens (Q5033201) → 5.6 (applies to part (P518) "max aperture"); 32 → (applies to part (P518) → "min aperture") en:Aperture I like to add the aperture to the lenses, which has wiki data item. For Canon we have currently lens items, where it would make sense to add this aperture.

#### Motivation

I like to add this value to the photo lenses, which have an item in Wikidata. GodeNehler (talk) 17:06, 6 June 2019 (UTC)

#### Discussion

•   Support -- 20:42, 8 June 2019 (UTC)
•   Support NMaia (talk) 10:18, 10 June 2019 (UTC)
•   Comment Make sure to distinguish this from Property:P6790 (f-number) or list it as a related property. Infomuse (talk) 03:32, 14 June 2019 (UTC)
•   Comment @Infomuse Thank you for the hint. As I am not a nativ speaker for english, and checking this issue again, I got the impression that 'f-number' might be the better Property, as 'aperture' seams to be the mechanic, but 'f-number' is the value, which I like to add. But in the Lens articles, like mentioned above, and in the template is the term 'aperture'. So I am not sure what is correct. The second issue: I have just add the 'f-number' to the Samyang 500mm f/8. There I got the warning 'Entities using the f-number property should be instances of photograph (or of a subclass of it), but Samyang 500mm f/8currently isn't.' From that I got the Impression that the 'f-number' is the real value, with which a picture is taken. So not absolutely clear for me. --GodeNehler (talk) 07:51, 15 June 2019 (UTC)
•   Comment After thinking about the issue, I got to the conclusion, that aperture is the correct term as aperture means the mechanical construct, which is correct for a lens. --GodeNehler (talk) 19:21, 20 June 2019 (UTC)
•   Comment A range is not sufficient because there are 2 different kinds of aperture ranges. First, some zoom lenses have different maximum apertures depending on the selected focal length (for example, w:en:Sony FE 28-70mm F3.5-5.6 OSS). Second, at a given focal length, a lens has a minimum and maximum possible aperture that the photographer can select. So we really need 4 numbers to characterize lens aperture ranges as commonly specified (min/max aperture when zoomed wide/tele). 2620:0:1000:3216:5413:4AF0:7532:8655 22:30, 21 June 2019 (UTC)
•   Comment The IP is right. This can be fixed with the possibility to add up to 4 values. Maybe there is a need to add infos like 'minimum aperture', 'maximum aperture' for prime lens, 'minimum aperture at maximum focal length', 'maximum aperture at maximum focal length', 'minimum aperture at minimum focal length', 'maximum aperture at minimum focal length' for zoom lenses and 'fixed aperture' e.g. for mirror lenses. --GodeNehler (talk) 16:38, 28 June 2019 (UTC)
•   Comment This proposal is not ready: clearly it should not have "Property" as datatype. A "Property" datatype means that the values of this property will be properties themselves. Please pick an appropriate datatype and add examples which are consistent with that choice. − Pintoch (talk) 21:06, 23 July 2019 (UTC)
• @Tinker Bell: Thanks for fixing the datatype - however, the examples don't have a "quantity" value right now - can you fix them to do that? Or perhaps GodeNehler can take care of this? Do you still think we need this property? The description also should be fixed (needs to be shorter, can't have wiki text or links). ArthurPSmith (talk) 16:55, 22 August 2019 (UTC)

I fixed the examples. But, I think there is, at least, two ways to store the data: for example, Canon EF 1200mm lens (Q5033201):

Storing each value in one statement
quantity 5.6 (qualifier applies to part (P518) "max aperture"); quantity 32 → (qualifier applies to part (P518) → "min aperture")
The other way, is calculating the average of maximum and minimum aperture, and storing it as the main value, and using upperBound and lowerBound to specify the range of aperture
quantity 18.8 (bound: 13.2)

The average is obtained doing ${\displaystyle (5.6+32)/2=18.8}$ , the bound, ${\displaystyle 32-18.8=13.2}$  and ${\displaystyle 18.8-5.6=13.2}$ . For fixed values, bound=0. We can obtain the minimum and maximum values adding or substracting 13.2 to the average. I know, it's a lot harder, but it allows using one statement for each range. -- 03:34, 23 August 2019 (UTC)

### number of pins, number of pin positions

Under discussion
Description 2 related properties: number of pins: number of contacts that an electrical connector has (excluding any grounding shroud not used for communication) number of pin positions: number of positions in an electrical connector, including empty or keyed positions electrical contact (Q394001) Quantity "num_pins" in en:template:Infobox connector; "contacts" in w:en:Template:Infobox CPU socket item: Subclasses of electrical connector (Q2119531). optical fiber connector (Q2296938) could be added later, pending discussion of how to handle optical module (Q48740842)s (which have electrical contacts on one end and optical connections on the other). positive integers none USB-C connector (Q58051489) → "number of pins" → 24 → "number of pin positions" → 24 NEMA 5-15 (Q24288456) → "number of pins" → 3 → "number of pin positions" → 3 6P2C modular connector (Q64831598) → "number of pins" → 2 → "number of pin positions" → 6 Intel HD Audio connector (Q64764371) → "number of pins" → 9 → "number of pin positions" → 10 citation: https://www.intel.com/content/www/us/en/support/articles/000005512/boards-and-kits/desktop-boards.html Socket F (Q1475023) → "number of pins" → 1207 → "number of pin positions" → 1225 Annotating items for electrical connectors. They could also be generalized to optical fiber connectors, since it's fundamentally the same concept. eventually complete (Q21873974) When only "number of pins" is specified, "number of pin positions" can be populated with the same value. Wikidata:Property proposal/contact area count Q2119531

#### Motivation

For annotating items for electrical connectors (see connector (P2935)).

Why are 2 properties needed? Some connectors have additional positions which are not filled. For example, the RJ11 w:en:Modular connector has 6 physical positions, but only 2 of them are populated. Similarly, the Parallel ATA (Q230360) data connector has 40 positions but only 39 pins, since one position is keyed. The unfilled positions should be counted when the connector's conventional numbering includes them.

Aliases: replace "pin" with "contact" or "conductor"; same without the initial "number of" 2620:0:1000:3216:5413:4AF0:7532:8655 23:59, 21 June 2019 (UTC)

Notified participants of WikiProject Informatics 169.234.25.175 20:28, 5 July 2019 (UTC)

#### Discussion

• In principle, we could do it by combining qualifiers with an entity for a pin; there are just some practical issues:
• It's not totally obvious for an editor which combination to use, and I don't see a way to hint recommended values. For example, quantity (P1114) with applies to part (P518) looks just as plausible (even if you're not supposed to use it that way). Also, people might use other elements besides the intended "pins" and "pin positions", e.g. pogo pin (Q1400617), wire (Q551997), or lead (Q947546). This will make querying more difficult.
• It's easier to express a constraint that the "pins" and "pin positions" should be specified together when they are expressed as a property.
• We might want to generalize this to support w:en:optical connectors; we would then have to add some items for pretty abstract concepts that encompass "electrical contact", "termination of a single optical fiber" (is there even a term for that?), and positions thereof. These would be hard to find.
In any case, there are lots of existing "number of X" properties, where X is a domain-specific part that an item contains. 2620:0:1000:3216:5413:4AF0:7532:8655 20:39, 25 June 2019 (UTC)
•   Support Seems like a fine idea. —Scs (talk) 11:18, 30 June 2019 (UTC)
•   Split support and oppose   Oppose For the given examples, RJ11 is only valid for countries that only host 2 wires. You can find RJ11 with 4 wires in 6 positions. RJ45 can also be used to replace RJ11, so RJ11 and RJ45 will have several possibilities. In addition, you write "electrical connector" which is quite broad: you give an example of an IC, which enters the electronic domain. With an electronics training, you can find a multitude of cases (so number of pins variable) for a single component (therefore for a single manufacturer and a single function and sometimes with a single denomination). The differences are according to the use of the component: assembly, power, disposition, etc. For the multilingual side of WD and the complexity of the domain (electricity), I fear that this future property brings errors. Of course, in obvious cases, this property will work, but contributors will not stop there. —Eihel (talk) 17:15, 11 July 2019 (UTC)
• Thanks for the feedback!
• Regarding RJ11, the Wikipedia article explicitly says RJ11 requires a 2-wire connector (without citation); if you have better information please update that. I switched the example to 6P2C modular connector (Q64831598) for precision, which I forgot to do earlier.
• I'm not sure what IC you're referring to, but assume you're talking about the CPU socket. I'm aware that a given IC can be packaged in multiple ways, but as far as I've seen, a given CPU socket necessarily has a well-defined number and arrangement of pins, so I don't see the issue.
• Regarding the risk of misuse, would a property type constraint (should be used on connectors only and not ICs or other components) address this? I'll update the proposal.
73.202.12.249 23:22, 17 July 2019 (UTC)
1. w:fr:RJ11#Belgique. Indeed, 6P2C is normalized in the sense of the use of pins.
2. Yes, CPU sockets remain the same as far back as I can remember. But I suggest you look for the term 7805 on your search engine (only browse images to make your life easier). It is a simple CI used in voltage regulation and there is a multitude of form, manufacturer, etc. , so several possibilities. And it's the same for a multitude of CIs, from the simplest to the most complex. Sorry. There is conflicts-with constraint (Q21502838)
relation (P2309)instance or subclass of (Q30208840)
class (P2308)electronic component (Q11653)
constraint status (P2316)mandatory constraint (Q21502408)
but this restriction will overshadow many items (In addition I do not know if it works!)
3. In the content of pages linked to the infobox on enwiki, it seems to be appropriate. 78xx does not contain a number of pins and the page does not contain this infobox. —Eihel (talk) 03:26, 28 July 2019 (UTC)
•   Support I had pretty much the same ideabut called it "contact area count. The reason is that eg. an LGA CPU has no pins. So I searched for a more general name that can be used for multiple things. number of pin positions is an interesting idea, however I'm not sure if this is really the way to go.
An example: A CPU socket has 1000 pin positions. CPU a) has 900 pins, because it's missing some workstation ECC RAM functions. CPU b) has also 900 pins, but not the pins for ECC RAM, but for the ones for CPU interconnects (so a single socket setup). CPU 3) has only 800 pins. It supports CPU interconnect and ECC RAM. He 200 missing pins are because it's a low end version that does not use as much power. How would you include that for the socket (and is the socket the right place to collect that information or should this rather be collected in the CPU item)
A second example: The Type 2 connector that is used to charge electric cars has 7 pins. The maximum output is ~43 kW with 7 pins. For slow charging out of eg. Schuko plugs it is about 3 kW and here only 5 pins are used. It is the same connector and the same layout. One charging type just misses 2 metal connectors. --D-Kuru (talk) 11:58, 2 August 2019 (UTC)
Comment It sounds like maybe the item for the interconnection standard should list in some way the meaning of all the pins? Though that might require an item for each pin position that further describes it? Like, pin 3 carries this signal with this voltage, etc.?? And then items that conform to that standard would specify that conformance, and which specific pins they actually use? ArthurPSmith (talk) 18:08, 2 August 2019 (UTC)
If it's not an open standard you will never now why one pin is used and the other isn't. A description for every pin is just not usefull in my opinion. In my opinion a "number of used pins" is not really ncecessary since a configuration can change over time and with the used device. If eg. a CPU socket hast 4000 pins and a CPU that fits the socket has 3000 pins, the number of pins for the socket is still 4000 (even some are not used - for now - but could be used at some point) and the CPU also still has only 3000 pins. For me, this applies also for eg. USB or SATA where one pin isn't in use. If USB version 2.0 uses 10 out of 20 pins, the number of pins would be tagged as 10 on the USB connector side. If USB 3.0 uses 20 pins, the pin information could be tagged for version 2.0 and 3.0. But you would not have to set any information about how many pins are not used in the USB connector. What if the USB connector is used anywhere else for some other connection that actually uses all 20 pins right from the start. It's an open standard, so this could happen quite easily. --D-Kuru (talk) 22:07, 6 August 2019 (UTC)
•   Support Interesting idea. I'm curious to see how it goes. --- Jura 09:05, 4 August 2019 (UTC)
•   Comment So if 2 properties are actually needed here, could somebody split the template into 2 separate proposal templates with the appropriate examples etc, to make it a little easier on the property creator(s)? ArthurPSmith (talk) 17:09, 7 August 2019 (UTC)
•   Comment An idea: As far as I saw there is has parts of the class (P2670) which can be combined with an item and you can insert a value in that item. I saw this for CPUs where L1, L2 and L3 cache is listed in said property. Is this an OK thing to do or is a property prefered here? If it would be fine to use items instead of properties this could be solved quite easy. --D-Kuru (talk) 13:09, 15 August 2019 (UTC)

### 2018 subscribers

Under discussion
Description (qualifier only) number of subscribers in 2018 Quantity qualifier for subreddit (P3984), etc. >1 none Spain (Q29) subreddit (P3984): es → 10,677 Spain (Q29) subreddit (P3984): spain → 15,414 Internet Relay Chat (Q73) subreddit (P3984): irc → 6,206 Ariana Grande (Q151892) Instagram username (P2003): arianagrande → 147,023,953 Katy Perry (Q42493) Twitter username (P2002): katyperry → 107,659,952 Number of ids with number of subscribers (P3744)-qualifier: Twitter 80000, Subreddit 2500 change 2018 data to the above number of subscribers (P3744)

#### Motivation

We probably agree that the numbers are useful, but the current qualifier number of subscribers (P3744) doesn't work that well. We haven't really come up with a good solution for this yet. Maybe the following could work: we could store previous years in separate qualifiers. Above a proposal for 2018. If we have earlier data, we should create qualifiers for the relevant years as well. Recent project chat discussion here, another approach was discussed at Number of twitter follower. (Add your motivation for this property here.) --- Jura 06:32, 23 June 2019 (UTC)

Options:

• (A) this proposal (see above)
• (B) overwrite number with new data
• (C) add several statements for the same account, each with a different point in time qualifier (or retrieved date in reference): sample, sample 2
• (D) create an item for each account and add the number of subscribers there
• (D0) for any number of subscribers
• (D1) if the number of subscribers exceeds a threshold (e.g. 10,000,000 subscribers). Sample: Q42493#P2002 and Q65665844
• (E) create a property "number of <service> users" and use point in time qualifier to differentiate them ( previous proposal)
• (F) add multiple number of subscribers (P3744) qualifiers to the same statement. This would make it difficult to link them to a date.
• (G) develop qualifiers on qualifiers. This is currently not planned and IMHO unlikely to happen.
• (H) store a datapage for all on Commons (not queryable, possibly not accessible even by LUA)
• H0 annually

--- Jura 15:22, 5 July 2019 (UTC), updated 09:05, 25 July 2019 (UTC)

I crossed out the ones the I don't think are pratical/currently feasible. --- Jura 04:41, 25 July 2019 (UTC)

#### Discussion

Sounds like the usual qualifiers of qualifiers problem. Generally we resolve this by creating an item - do we have/want items for youtube channels, twitter feeds, etc? ArthurPSmith (talk) 14:53, 24 June 2019 (UTC)
I think we don't, at least not for each that currently uses P3744 --- Jura 09:35, 25 June 2019 (UTC)
My first impulse would be that we don't want to store the data for the subscribers of the reddit about spain for every year. There's already a lot of data in the items of countries, more data increaes page loading time and few of the people who are looking at the item for the country care about the reddit followers. ChristianKl❫ 09:28, 25 June 2019 (UTC)
There are >2000 reddits with that data. I suppose we could skip the country ones. Btw, this isn't meant to be limited to reddit --- Jura 09:35, 25 June 2019 (UTC)
Question The number of subscribers can change over a year. Will this property store the number at 01.01.2018 00:00:00 or at 31.12.2018 23:59:59 or at an arbitrary other point in the year? --Pasleim (talk) 11:30, 25 June 2019 (UTC)
The last, maybe even all three, but most reddit numbers are from May. I don't expect the numbers for previous years to change. --- Jura 11:48, 25 June 2019 (UTC)
Oppose why not just use point in time (P585)? --DannyS712 (talk) 16:22, 28 June 2019 (UTC)
•   Question @DannyS712: I'm not sure if I understand. Can you do a sample in a sandbox, e.g. with current and 2018 number of subscribers? --- Jura 16:25, 28 June 2019 (UTC)
@Jura1: if point in time (P585) were allowed to be used as a qualifier, then Special:Permalink/970594325 wouldn't show errors, and would work --DannyS712 (talk) 16:29, 28 June 2019 (UTC)
• Even. I don't think it's a good idea to add P3984 (value "spain") several times. (BTW, this generates also a "distinct value" constraint violation). --- Jura 16:34, 28 June 2019 (UTC)
@Jura1: That violation was only because the value "spain" is used elsewhere - Special:Permalink/970611124 generates no such error --DannyS712 (talk) 17:12, 28 June 2019 (UTC)
Good point. I corrected my comment. The option was mentioned here, but not implemented. --- Jura 21:32, 28 June 2019 (UTC)
Comment What is range of it? You can have different number of subscribers every year, month, day, hour and probably even minute. Eurohunter (talk) 21:34, 29 June 2019 (UTC)
• The 2018 qualifier would be for data from January 1 to December 31, but as mentioned, I don't expect more than we already have, e.g. those from May for subreddit. --- Jura 17:21, 30 June 2019 (UTC)
• In any case, that would prevent 2018 data from being overwritten by 2019 data [3]. --- Jura 17:05, 4 July 2019 (UTC)
•   Comment Imho "number of subscribers" should only be used when it is accompanied by "point in time", otherwise it does not make much sense. But as soon point in time is used the number is valid. --Gereon K. (talk) 20:22, 4 July 2019 (UTC)
• @Gereon K.: The earlier statement had the date in "retrieved [on]" [4]. Would you just overwrite all these numbers continuously? I find it a bit odd to use the qualifier "point in time" on statements where the main value is rarely subject to change. --- Jura 22:07, 4 July 2019 (UTC)
• @Jura1: Yet the number of subscribers changes daily, so it is valid only at a certain point of time. This would be exactly the same date as "retrieved on", but "retrieved on" is meant for the source. And the source regarding the used name and the number of subscribers in this case is Twitter itself. --Gereon K. (talk) 06:12, 5 July 2019 (UTC)
• @Gereon K.: According to your last sentence it is archived version for example in Wayback Machine, version you can access not directly Twitter. Eurohunter (talk) 15:00, 5 July 2019 (UTC)
• I'm aware of that. As neither is optimal, I wrote this proposal. Also, above, I listed various other options that came up. --- Jura 15:17, 5 July 2019 (UTC)
•   Comment Well, I'm already wondering why P3744 does not already have mandatory qualifier constraint (Q21510856). Since the property changes over time, a date must be mandatory (just as the fact that there is no "number of subscriber march 2018"). My choice: (F), but improved. —Eihel (talk) 19:44, 11 July 2019 (UTC)
• @Eihel: mandatory qualifier constraint (Q21510856) wouldn't have any effect in the above use case, as here P3744 is used as a qualifier. To be sure what you have in mind, would you do a sample for "(F), but improved" in Q4115189, preferably using data that already exists on Wikidata? It seems to me that (F) is the least desirable solution. --- Jura 09:47, 13 July 2019 (UTC)
@Jura1: Sorry for the delay, here's my thought:

Effectively, the change will be on subreddit (P3984) with mandatory qualifier constraint (Q21510856) and point in time (P585). And the Items will become like this:

Properties with a single use by Item (Q19474404) must be modified at the same time. Idem for all Prop. —Eihel (talk) 03:01, 24 July 2019 (UTC)
• @Eihel: Thanks. Actually, I had seen this more as option (C) above. After thinking more about the various options, I'd move to using a combination of D1 and either C or A. --- Jura 03:34, 24 July 2019 (UTC)
@Jura1: Well, I'm always at the same point. I do not understand more D1: if I doubt on a Property, it is not to add a multitude of Items instead. First of all, I was thinking about the economy: having P's or Q's for 2016, 2017, 2018, 2019, I think it's not very productive, not very db. I would take the problem upstream, hence my first intervention. Any property likely to change over time must be accompanied by a temporal sense. Example: We have mass (P2067), on the other hand we do not have several Properties to say that one is in kilogram (Q11570) and the other in ounce (Q48013), etc. Your proposal is "2018 subscribers", which means that there will be "2019 subscribers" and "2020 subscribers" (etc.)? Bof! If there is no date for Twitter, reddit or Instagram, you have to put it. If there is no date for any object likely to change in time… QED —Eihel (talk) 05:24, 24 July 2019 (UTC)
Any of the options above have also disadvantages. I don't think there is a clear advantage of (C) over (A). At some point we have to opt for one or the other. BTW, I haven't added any of May 2018 subscriber data. The date is currently set with "retrieved date". --- Jura 05:31, 24 July 2019 (UTC)
So   Oppose for the proposal —Eihel (talk) 10:30, 25 July 2019 (UTC)
•   Comment added another option: D1. --- Jura 12:45, 13 July 2019 (UTC)
•   Comment I made a bot request for D1 at Wikidata:Bot_requests#Monthly number of subscribers. --- Jura 14:24, 19 July 2019 (UTC)
•   Oppose I would favour a solution involving storing all the subscriber data as tabular data on Commons, possibly with one data page per account per year (this would prevent the data pages from exceeding the page size limit). I'm surprised this hasn't been mentioned yet – Wikidata is an inefficient method of data storage compared to tabular data (measured by both time and density), and there are so many data points (more than one per second per account, if we were to gather all the data points) that it would quickly become impractical to store the data in Wikidata even if the data were only updated once a week. The newest data point would still be obtainable with Lua. There might be problems with database rights, but I don't think this would become an issue. Jc86035 (talk) 08:53, 25 July 2019 (UTC)
• It seems that people overwrite subscriber numbers daily for some accounts (go figure why?), but I don't think anyone suggest to store all weekly values, so the suggested approaches should currently be practical and shouldn't become impractical anytime soon.
If there would be a data page on Commons, we could obviously link that, I added it as an other option above. I don't think this would be queryable anytime soon. --- Jura 09:05, 25 July 2019 (UTC)
• I do not see the relevance of saving this kind of data more than once a month. —Eihel (talk) 10:30, 25 July 2019 (UTC)

### default description for instances

Under discussion
Description description that should be displayed/add by default to instances of this class (that it, to items which have a statement < class > instance of (P31)   < {{{2}}} > if the item « class » has a statement with this property. To include property value, use \$ and the property, e.g. to include \$P571 for placement of the value of P571. Item items with many instances, e.g. from Wikidata:Database reports/Popular items items with suitable descriptions as labels, including \$Pnn for property values Wikimedia disambiguation page (Q4167410) → Wikimedia disambiguation page (Q64875536) (applies to max. 1,326,946 of 57,662,380 items, 2.3%) film (Q11424) → new item with "film"@en as label film (Q11424) → \$P571 film by \$P57 (Q64875670) Wikimedia category (Q4167836) → new item with "Wikimedia category"@en, etc as label (applies to max. 4,309,102 of 57,662,380 items, 7.5%) scholarly article (Q13442814) → new item with "article published \$P571"@en, etc as label (applies to max. 21,731,437 of 57,662,380 items, 37.7%) Wikimedia template (Q11266439) → .. (applies to max. 889,411 of 57,662,380 items, 1.5%) human settlement (Q486972) → human settlement in \$P131, \$P17 (Q64896833) (applies to max. 460,153 of 57,662,380 items, 0.8%) ) store what bots currently use (continue to) use by bots phase 2: make available for a Wikibase function to display by default maybe 10-20 items that apply to > 30,000,000 items (50% Wikidata's items)

#### Motivation

Initially bots could add the provided description (as they already do now). Eventually it's preferable that Wikibase displays/adds that by default, similar to what is being done for lexemes (based on language/lexical category).

The numbers above are just a rough estimate. If you have better ones, please add them.

@Милан Јелисавчић, ValterVB, Emijrp, Edoderoo, Mr. Ibrahem: @Daniel Mietchen, Ivan A. Krestinin, Liridon, Renamerr: who operate bots working on some of the above. @Multichill: who started a discussion on project chat. @Lydia_Pintscher (WMDE): re possible phase 2, --- Jura 16:51, 29 June 2019 (UTC) @TomT0m: who brought it up (at least afaik) . --- Jura 17:02, 29 June 2019 (UTC)

#### Discussion

oh yeah that’s an old one I forgot. As far as I remember my proposal was a bit different and to use a wikitemplate as a pattern to do that, as there is already stuff to deal with linguistic issues like grammatical agreements in Mediawiki. Something possible would be to use an Special:ExpandTemplates API call to get the description. But it’s more complicated to create a template. author talk page 18:06, 29 June 2019 (UTC)

•   Oppose for several reasons:
1. Description does not require examples of data type "item"
2. There are already properties that explain the items:See here
3. The labels of the proposed items in the examples match the labels of the original items David (talk) 06:47, 30 June 2019 (UTC)
• (1) it shouldn't be a general requirement. It just applies to a series of frequent types. Compare, e.g. with lexeme entities where the description is entirely generated by structured data. (3) indeed, that's true for some. --- Jura 10:14, 30 June 2019 (UTC)
• I'm a bit confused. We want to introduce a property for the description, while there is already a description for that. What problem do we try to solve here? People that create items already do not take the effort to add a description, why would we expect (hope?) that they would add a property with the description instead? Edoderoo (talk) 08:54, 30 June 2019 (UTC)
• @Edoderoo: It’s just the opposite ! The proposal is not to put, in the example, this property on any movie item, it’s to put the property on the film (Q11424)     item. Then the statement can be used on any item with a
instance of (P31)   < {{{2}}} >
statement (or a subclass of it potentially) to autogenerate a description by data consumer if there is no description in the language for the item. It could be used for example by the autodesc project or templates like `{{Autodescription}}`. author talk page 09:54, 30 June 2019 (UTC)
• Right, basically that is what my bot does, on some cases with a bit more intelligence. We could integrate that in the wiki-software. But that also means that this is not a proposal for a property, but a proposal to change how the information in existing properties is (re)used. Edoderoo (talk) 11:15, 30 June 2019 (UTC)
• @Edoderoo: Mmm no, that means that your bot or Magnus’ tool and other tools could reuse informations from this property in cases he does not know how to handle some item, if we choose the path of filling by bot. It does not imply anything on how information is reused by clients if they just choose to ignore it. If we choose to integrate automated descriptions on Mediawiki this property could as well be useful, for example if there is a Mediawiki configuration option (or special page, in the spirit of MediaWiki:Wikibase-SortedProperties which can trigger some special behavior by Mediawiki) that associates, say, an item with a shape expression (maybe the future property Wikidata:Property proposal/Shape Expression for class if it’s created) with a pattern. For example there could be a special page with content « Pdefault description for instances ; PShape Expression for class » and mediawiki would autocompute the descriptions for items that validates « PShape Expression for class ». To get something more robust and smarter as your bot can do, this could be instead of a raw string with « \$ » symbols, a mediawiki template page that is specified to render the description however, as noted in my first comment. author talk page 12:19, 30 June 2019 (UTC)
•   Comment Thanks for your feedback. I expanded the samples a bit, maybe it's more clear now. @ديفيد عادل وهبة خليل 2, Edoderoo: --- Jura 10:14, 30 June 2019 (UTC)
• I still do not convinced of your responses and do not see any benefit from the proposed property David (talk) 10:28, 30 June 2019 (UTC)
• Well, the main benefit would be in phase 2. --- Jura 10:41, 30 June 2019 (UTC)
• @ديفيد عادل وهبة خليل 2: The point is that there is already in use tools that generates autodescriptions, see the autodesc project (@Magnus Manske: who can probably say stuffs about this), that store the way the description is generated off wiki. Doing this storage « on wiki » would probably make them more useful as it would make the contribution way more accessible to non programmers. author talk page 10:44, 30 June 2019 (UTC)
• I'd like to see some input from people who have done auto-descriptions (like Magnus Manske). Is it really necessary to have a separate template for each class and language, or can something more general be done somehow? ArthurPSmith (talk) 15:08, 1 July 2019 (UTC)
• I think there should be at least one template per class and possibly additional ones if the description is to include the label of another property (e.g. see the film sample above). @Magnus Manske: --- Jura 15:31, 1 July 2019 (UTC)
• I think Magnus (without looking at the code) has additional « default » rule in the abscence of a template. That can be seen as a « default » template for any item : if the item has an instance of (P31) or subclass of (P279) statement, he just puts the label of the value of the statements as a default description, separated by commas or conjunctions like « and ». This could be implemented if we could express rules such as« if the item matches some shape expression [in this case there is a P31 or P279 statement] then generate [that kind of description].
Maybe Magnus has also rules such as « if there is a author (P50)   statement, add « by [the statement value] » to the description previously created. author talk page 15:46, 1 July 2019 (UTC)
• I don't think this is necessary, since bots already sort of do this without the property. I also find that a lot of Wikipedians consider Wikidata descriptions generic and sterile, so forcing this to be connected solely to P31 might be detrimental even compared to the current situation. Jc86035 (talk) 16:39, 8 July 2019 (UTC)
• A good default description uses what information is available. "article published \$P571" would fail when there's no P571. We would need logic that says that in those cases the word "published" gets also ommitted. I currently think that ideally we would have a template system where templates can use complex lua logic. ChristianKl❫ 13:57, 17 July 2019 (UTC)
• I think the item could specify which properties are required. I don't think coding the entire logic into every bot and every template is helpful. --- Jura 15:10, 19 July 2019 (UTC)

### image of bone or fossil record

Under discussion
Description image of the fossil, bone or skeleton of this taxon Commons media file taxons File:. Vespersaurus (Q64836111) → File:Vespersaurus foot.png pig (Q787) → File:Domestic pig skeleton at MAV-USP.jpg MISSING

#### Motivation

It's common for entries for taxa, especially extinct ones, to have at least two suitable images: a photo/illustration and the skeletal remains/fossil for it. It would be good to have both in their relevant entries. NMaia (talk) 06:08, 15 July 2019 (UTC)

#### Discussion

File:Domestic pig skeleton at MAV-USP.jpg skeleton (Q7881) and
File:Vespersaurus foot.png fossil (Q40614)?-- 16:46, 15 July 2019 (UTC)
•   Oppose Such as the explanation above, the existing property is sufficient David (talk) 06:44, 16 July 2019 (UTC)
•   Comment In general, people prefer just one value in P18, so a selection with a distinct property could indeed be helpful. I'm not entirely convinced by the suggested wording, but I'm not really a specialist in the field. --- Jura 13:34, 20 July 2019 (UTC)

### value group number

Under discussion
Description (qualifier only) an higher level of series ordinal used to separate various lists already with series ordinal (P1545) String any 雨 (Q3595028) fanqie (P5523) 王 (Q2391630) (series ordinal (P1545)=1, value group number=1), 矩 (Q55806623) (series ordinal (P1545)=2, value group number=1) 雨 (Q3595028) fanqie (P5523) 王 (Q2391630) (series ordinal (P1545)=1, value group number=2), 遇 (Q55806688) (series ordinal (P1545)=2, value group number=2) MISSING Use as a qualifier of fanqie (P5523) and ideographic description sequences (P5753)

#### Motivation

See User_talk:Ivan_A._Krestinin#Bot_edits_on_P5523 as the background of the proposal. GZWDer (talk) 16:24, 18 July 2019 (UTC)

#### Discussion

Item 笈 笈 笈 Equivalence Fanqie (initial) Fanqie (final) References A 其 立 Guangyun (Q2189818) A 極 入 Jiyun (Q35792) A 忌 立 Hongwu Zhengyun (Q10958946) B 其 輒 Guangyun (Q2189818) B 極 曄 Jiyun (Q35792), Hongwu Zhengyun (Q10958946) C 楚 洽 Guangyun (Q2189818) C 測 洽 Jiyun (Q35792), Hongwu Zhengyun (Q10958946) D 巨 業 Guangyun (Q2189818) D 極 業 Jiyun (Q35792)

There are 9 pairs of data, each consisting of an initial and final character, and these 9 pairs can be further grouped into four equivalent pairs of data (A,B,C,D). Are there any existing properties that can be used to handle this situation? KevinUp (talk) 21:00, 18 July 2019 (UTC)

Perhaps the value group number can be modified to "A1, A2, A3, B1, B2, C1, C2, D1, D2" or "1a, 1b, 1c, 2a, 2b, 3a, 3b, 4a, 4b" to mark the equivalence of certain data sets? KevinUp (talk) 21:12, 18 July 2019 (UTC)

Opensofias
Tobias1984
Micru
Arthur Rubin
Cuvwb
TomT0m
Tylas
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc   Notified participants of WikiProject Mathematics for suggestions on how to handle this situation. The proposed property may also have other applications. KevinUp (talk) 19:35, 20 July 2019 (UTC)

•   Comment @KevinUp: is the suggestion here to have a general mechanism to handle two-dimensional indexing, not just something specific to these characters? That sounds like a reasonable thing to do in principle, but in practice the items would still show up as a one-dimensional list within the Wikidata UI. "Series ordinal" doesn't have to be just a number, you could for example combine letters and numbers, or have two numbers separated by a comma or other special character. Is this really needed? ArthurPSmith (talk) 18:49, 22 July 2019 (UTC)
@ArthurPSmith: Yes, the idea is to have a general mechanism to handle two-dimensional indexing that can be applied not just to these characters. In the examples given above, "value group number" is used to indicate that group 1, which is represented by (Q2391630) and (Q55806623) and group 2, which is represented by (Q2391630) and (Q55806688) are distinct groups that are not the same. The "value group number" does not indicate any rank but is used to indicate distinction. KevinUp (talk) 20:40, 22 July 2019 (UTC)
To add another layer of complexity, in the table I have prepared for the item "笈", there are four different groups (A,B,C,D) and each group can be described by more than one method, e.g. in group D, (Q55414074) (series ordinal 1) + (Q54873157) (series ordinal 2) and (Q54879270) (series ordinal 1) + (Q54873157) (series ordinal 2) are equivalent, so we could perhaps use a second character in the value group number, e.g. "4a", "4b" to indicate equivalence of the subgroups a and b within group 4. KevinUp (talk) 20:40, 22 July 2019 (UTC)
• If you are using series ordinal like 3a or 3.4, they are not much machine readable or queryable. Although this proposal (with only one property) does not work well in more than two dimensions.--GZWDer (talk) 20:58, 22 July 2019 (UTC)
@GZWDer: To solve the issues of [1] series ordinal such as 3a or 3.4 not machines readable [2] the property in this proposal not working well in more than two dimensions, I suggest the following: KevinUp (talk) 17:45, 25 July 2019 (UTC)
1. Replace fanqie (P5523) with two new properties: initial fanqie character and final fanqie character (as originally suggested by you) - This is because initial and final fanqie have different properties, i.e. the initial character shares the same initial consonant while the final character shares the same vowel, consonant ending and tone with that of the queried item.
2. Use series ordinal (P1545) for groups A,B,C,D in the example above (this would indicate that the fanqie readings are distinct).
3. Apply the proposed property (value group number/group ordinal) to values that have the same series ordinal. This is analogous to A1, A2, A3 in the example above.
For fanqie, values with the same series ordinal but different value group number/group ordinal are similar in a way, e.g. 其,極,忌 (initial fanqie from A1, A2, A3) all share the same initial consonant in Middle Chinese. KevinUp (talk) 17:43, 25 July 2019 (UTC)
• Thanks for the responses. So now I'm wondering, where did the proposed label "value group number" come from? Is that a common term used for these character representations, or is that something GZWDer came up with? If we are to do this I think I'd prefer a shorter name if possible. "group ordinal" perhaps? ArthurPSmith (talk) 19:19, 23 July 2019 (UTC)
No, it's not a common term used for these character representations. I also prefer a shorter name such as "group ordinal" as long as it has the meaning "higher level of series ordinal". KevinUp (talk) 17:43, 25 July 2019 (UTC)

### orientation

Under discussion
Description axis of alignment of an item, or direction perpendicular to its primary face (specify with P518 if necessary) orientation (Q2235286) Item items instances of direction (Q2151613) and its subclasses Statue of Liberty (Q9202) orientation east (Q684) migration of statements misusing direction (P560) direction (P560), angle from vertical (P4183)

#### Motivation

To migrate a large number of misuses of direction (P560), which is supposed to express a relative direction from the subject item toward the parent statement's value, where both items have a fixed location. This property will express how an item is aligned with respect to fixed axes, rather than the location of another item, and is thus not restricted to being a qualifier.

Also propose re-labeling direction (P560) to "relative direction" or "direction relative to subject" (and the equivalent in other languages) to mitigate its misuse. Swpb (talk) 18:40, 18 July 2019 (UTC)

#### Discussion

•   Comment. This is mostly going to be used on items for buildings. What orientation is for them should thus be specified. Is that what's perpendicular to the main entrance? We have to let this be clear. Thierry Caro (talk) 17:04, 19 July 2019 (UTC)
• Why do you think it will mostly be used for buildings? Only one of the examples is sort of a building; the biggest class of targets I know of are flags. Where it is used for a building and the intended face isn't clear, one can easily add a qualifier applies to part (P518) entrance (Q1137365) or similar. Swpb (talk) 18:38, 19 July 2019 (UTC)
• Whatever the examples are, I can see that this is going to be used mostly for buildings. But even if that is not the case eventually, I still believe that what 'orientation' means should be clarified or I would fail to support the proposal. What is the value that is to be expected for Painted Wall (Q49469925), for instance? Should it be southeast (Q6452640) because the cliff 'faces' that direction? Or should it be a new 'southwest-northeast' item because the edge of the canyon follows that direction? Again, are we speaking of what the main side of an object is perpendicular to or are we really talking about the direction it is parallel to? That is not obvious and may create problems in translation. Thierry Caro (talk) 05:17, 24 July 2019 (UTC)

The (IMO) only reasonable way to interpret "orientation" statements on buildings (or cliffs) – unidirectional value means face is perpendicular; bidirectional value means face is parallel.
• I understand the concern now, and I've added a property description (missed that when I made the proposal). Where this is used on buildings (or cliffs), the nature of the value resolves any ambiguity between parallel vs. perpendicular: intuitively, unidirectional (⟶) values like "west" indicate perpendicular, and bi-directional (⟷) ones like "east-west" indicate parallel: If I say United States Capitol (Q54109) is oriented "west", that can only mean that its front is on its western side. If it faced north or south, it could be said to be oriented "east-west", if we had such a bi-directional item, but it would never be said to be oriented just "east" or "west". (More likely though, it would just be said to be oriented "north" or "south", since, like most buildings, it has a distinct front and back.) Even though most users will never explicitly consider this uni=perpendicular/bi=parallel distinction, I think it follows intuition, and I have a hard time imagining anyone misinterpreting such statements. All the same, it can be documented on the property. Swpb (talk) 13:30, 24 July 2019 (UTC)
• Wouldn't it be preferable to have the buildings in a separate property? --- Jura 16:01, 25 July 2019 (UTC)
• I don't think so, but if excluding buildings from this property will get it created, then so be it. Right now, any ambiguity that could occur with this property is already occurring with direction (P560), on top of it being explicitly not meant for these applications. Maybe let's stay focused on the bigger problem, and someone can propose a special property for buildings if they want later? Swpb (talk) 19:40, 25 July 2019 (UTC)
•   Support I think it would be useful for describing blazons. -- 18:49, 19 July 2019 (UTC)

### x-offset

Under discussion
Description offset on the x-axis or primary axis, abscissa x-axis (Q25599399) Quantity if applicable SWSW block (Q65965927) → 0 block (Q66319570) NWNW block (Q65965923) → 0 block (Q66319570) SESE block (Q65965939) → 3 block (Q66319570)

### y-offset

Under discussion
Description offset on the y-axis or secondary axis, ordinate y-axis (Q26262125) Quantity if applicable SWSW block (Q65965927) → 0 block (Q66319570) NWNW block (Q65965923) → 3 block (Q66319570) SESE block (Q65965939) → 0 block (Q66319570)

#### Motivation

Maybe we have this somehow, but I don't think so. Feel free to add a property for z-axis. Above samples from w:Section_(United_States_land_surveying)#Subdivision_of_a_section (Add your motivation for this property here.) --- Jura 01:40, 29 July 2019 (UTC)

#### Discussion

Comment Could this be somehow done with our geo coordinates datatype? I realize this is for a relative coordinate vs absolute, but as presented here this seems to assume "x axis" = distance eastward, "y axis" = distance northward (I think?) which would otherwise be rather arbitrary. Is "x axis", "y axis" actually the terminology used in the original source for this proposal? ArthurPSmith (talk) 17:42, 29 July 2019 (UTC)
Yeah, that was my first thought too, but the datatype has degree as unit hardcoded. For PLSS terminology, see w:Public_Land_Survey_System#Commonly_used_terms; for the axes, w:Cartesian coordinate system. --- Jura 14:32, 30 July 2019 (UTC)
PLSS apparently uses "range" for east-west coordinate, and "township" for north-south, according to your source? Those terms seem confusing though. Anyway, "x" and "y" are definitely not defined. If we do have wikidata properties for this, we definitely need a clearer name. Maybe just "eastward distance" and "northward" distance", if that's how these should be defined? ArthurPSmith (talk) 17:19, 30 July 2019 (UTC)
By the way, we already have elevation above sea level (P2044) as a property for z-axis, although perhaps a relative measure is needed there too - "relative altitude"? ArthurPSmith (talk) 17:21, 30 July 2019 (UTC)
Reading the article last week, I concluded that a township is a much larger unit than a block or a section. I don't think the terminology needs to be identical. --- Jura 11:29, 5 August 2019 (UTC)
•   Comment @ديفيد عادل وهبة خليل 2, Nomen ad hoc: I updated the sample. I think it's sufficient to define it in terms of blocks. Compare Subdivision_of_a_section. What do you think. --- Jura 11:29, 5 August 2019 (UTC)
OK. Thank you. Nomen ad hoc (talk) 13:19, 5 August 2019 (UTC).
• But "block" is an area, not a distance. This whole thing doesn't make sense to me - would these properties only apply to the 16 stated items? Or where else would it be used? If it's less than 100 or so items that could use this, I   Oppose special properties just for this purpose. ArthurPSmith (talk) 19:06, 5 August 2019 (UTC)
•   Comment Prefer x-offset and y-offset as labels. There *might* be other contexts where this could be useful. Jheald (talk) 20:17, 5 August 2019 (UTC)
•   Comment thanks for your feedback. I updated the sample and label accordingly. Don't hesitate to improve it further. --- Jura 14:49, 9 August 2019 (UTC)

### contact area count

Under discussion
Description amount of contact faces of a certain device electrical contact (Q394001) int-number-invalid datatype (not in Module:i18n/datatype) "contacts" in w:en:Template:Infobox CPU socket property natural numbers only only full counting steps (no float values) Socket AM3 (Q876639) → Int number of contact pins LGA 2011 (Q748697) → Int number of contact fields DDR4 SDRAM (Q1189682) → Int number of contact slots Type 2 connector (Q2335519) → Int number of electric contact pins CPU socket items, DDR SDRAM items, EV charging connector items (I'm sure there are much more) eventually complete (Q21873974) Wikidata:Property proposal/number of pins, number of pin positions

#### Motivation

I got the idea for this when I was looking at CPU sockets here on wikidata. I was looking at an AMD CPU socket and thought could/should there be the pin count here on wikidata. Since this page exists, it does make sense for me since it's a unique property of a CPU socket that never changes and is already collected in information tables on Wikipedia.
My first idea was to name it "pin count". But since I wanted to use it not only for PGA, but also for LGA CPU socket I thought a bit and came up with "contact area count". If anyone has a better name, let me know!
When I thought about other uses outise of CPU sockets I realised that there are many items which have contact pins or areas and that this count is unique for them. So eg. DDR SDRAM bars, EV charging connectors, USB connectors, storage media (eg. FC or SD cards), cables (eg. Molex or SATA power cables). I found much use here witin the IT sector.
Since my work inside of the Wikimedia system focused much more on Commons I may need somebody to explain the structure of Wikidata in case I got something wrong. I hoped that I could get away with using an item, but it does not really look like it. If Q66061119 can not be used for that, don't forget to delete it. One thought I had (this is where the Wikidata structure information would be interesting) is that I also thought about that there could be pin count (PGA CPU sockets, EV charging connectors, CF cards) and area count (LGA CPU sockets, DDR SDRAM bars, SD cards). Not sure if this is really neccessary.
--D-Kuru (talk) 17:09, 1 August 2019 (UTC)

#### Discussion

Thanks for the link, I left a note --D-Kuru (talk) 11:58, 2 August 2019 (UTC)
• Does the "subject item" works ? --FabC (talk) 17:02, 8 August 2019 (UTC)
Sorry, I have no idea what your question is. Do you have more information for me/a wikilink? --D-Kuru (talk) 10:32, 9 August 2019 (UTC)
If you are referring to my question, I changed the "subject item" in the template of the Property proposal, labelled "Represents", i.e. item corresponding to the concept represented by the property, if applicable. I was asking if it fine. --FabC (talk) 11:18, 9 August 2019 (UTC)
Yeah, I was, but stupid me of course answered the wrong part of the discussion - I switched that. For the question: Yes, it's actually a pretty good fit. --D-Kuru (talk) 18:09, 9 August 2019 (UTC)

Notified participants of WikiProject Informatics ChristianKl❫ 13:11, 8 August 2019 (UTC)

•   Comment An idea: As far as I saw there is has parts of the class (P2670) which can be combined with an item and you can insert a value in that item. I saw this for CPUs where L1, L2 and L3 cache is listed in said property. Is this an OK thing to do or is a property prefered here? If it would be fine to use items instead of properties this could be solved quite easy. --D-Kuru (talk) 13:08, 15 August 2019 (UTC)

### Voting system

Under discussion
Description Voting system used for this election voting system (Q182985) Item item

#### Motivation

Use to allow linking elections to their voting systems (direct/indirect, etc). Thanks, --DannyS712 (talk) 23:19, 5 August 2019 (UTC)

Notified participants of WikiProject elections --DannyS712 (talk) 03:11, 6 August 2019 (UTC)

#### Discussion

•   Support --Trade (talk) 20:10, 10 August 2019 (UTC)
• tend to   Weak oppose, seems redundant with and . author talk page 12:22, 12 August 2019 (UTC)
•   Comment Anyway, allowed values should be « instance of voting system », not « subclass of voting system », or a specific election like would be an instance of « voting system ». And
instance of (P31)   < voting system >
does not make any sense. author talk page 12:28, 12 August 2019 (UTC)
Except that doesn't make sense - its not a subtype of the election system it uses. And I meant that the value of the property should be a subclass of a voting system. I'm not sure I understand what you mean in the second comment - its not
instance of (P31)   < voting system >
, but rather . --DannyS712 (talk) 12:55, 12 August 2019 (UTC)
@DannyS712: It may make perfect sense … if you consider the french label, which is scrutin de liste proportionnel, in english « proportional list voting ». Any proportional list voting is a voting, so we have
< proportional list voting > subclass of (P279)   < voting >
, any israely legislative election is a proportional list voting, so we have
< israely legislative election > subclass of (P279)   < proportional list voting >
, and September 2019 Israeli legislative election (Q64159775) is an instance of everything. If you choose that model you certainly not have to express in all elections items like September 2019 Israeli legislative election (Q64159775) which type of election they are because they are already classified as election of that type, with less redundancy.
instance of (P31)   < voting system >
then makes explicit how we classify elections, these are the subclasses we are looking for if we want the voting system, because there is other criteria with which we classify elections (for example any israeli legislative election is a national election, which make « israeli legislative election » a subclass of « national election »).
But I must admit I did not look in details to the english label and english definition of this item. If a voting system is a set of rule, it make perfect sense to link an election to a voting system. This set of rules defines a process, that is instanciated at each time this type of election type.
An election is a process in which some people are chosen for some offices or a decision is taken, (referendum),so
< election > subclass of (P279)   < process >
.
An election follows some rules, defined usually by a law : main regulatory text (P92). In a sense the rules entirely defines the process of the elections. The rules can be instanciated many times, for example the rules for the american president election are instanciated many times. In that sense the USA presidential election is … a voting system. If you see en:voting system it redirects to « electoral system », which is defined exactly like that, this is consistent. So it’s enough to say that the Trump election is a USA presidential election to link it to its voting system.
On the other hand, party-list proportional representation (Q31764), if you see the english article, is defined as a voting system … family, which changes everything. You would have to rename this property « voting system family » to be consistent, according to the examples. Then you are looking for instances of « voting system family » You don’t hav . So I think to make all this consistent, you would actually have 2016 United States presidential election (Q699872) voting system family indirect election (Q877353). But I think all this is essentally the same analysis as before, so this is redundant and not very useful as well, we can do better without this property at all … author talk page 09:44, 13 August 2019 (UTC)
•   SupportStudiesWorld (talk) 00:10, 13 August 2019 (UTC)
•   Support Need to document also the relation with main regulatory text (P92) (perhaps a costraint that there should be both or one implies the other?) --Sabas88 (talk) 07:18, 13 August 2019 (UTC)
Actually the regulatory text is tight to the election type, for example any israely legislative election (on a certain period of time) has the same rules. The statement should be made of items such as « israeli legislative election » to avoid redundancy, not on any election instances. It’s easy by a query or in lua to find the text if you know it’s an instance of « USA presidential election » then. author talk page 09:44, 13 August 2019 (UTC)
•   Oppose This seems like a good idea, but I don't think the current samples (and definitions) are up to it. It would be good to have items that actually describe the voting system used in a given election. Maybe "allowed values" should be instances, not classes. --- Jura 14:10, 20 August 2019 (UTC)

### Election called by

Under discussion
Description Election called by Item always incomplete (Q21873886)

#### Motivation

Clarify who called a snap election. Currently, sometimes has cause (P828) is used, but the cause is different from who actually called an election. For example, isn't correct, because the cause was the inability to form a government (failure of Greek government formation, May 2012 (Q5601958)). Hope this makes sense - feel free to ask if anything is unclear. Thanks, --DannyS712 (talk) 23:22, 10 August 2019 (UTC)

Notified participants of WikiProject elections --DannyS712 (talk) 23:24, 10 August 2019 (UTC)

#### Discussion

•   Support David (talk) 05:39, 11 August 2019 (UTC)

Notified participants of WikiProject every politician ChristianKl❫ 18:50, 11 August 2019 (UTC)

•   Question: Would this apply to 2017 United Kingdom general election (Q25052149) as well DannyS712 (talkcontribslogs)? – 21:40, 11 August 2019 (UTC)
Yes, it would - it was called by Theresa May --DannyS712 (talk) 21:45, 11 August 2019 (UTC)
• Perhaps this data should be stored in the more general items for the type of election instead. --Yair rand (talk) 23:36, 12 August 2019 (UTC)
• Except even elections of the same type, like Knesset elections, are called by different people for different elections. --DannyS712 (talk) 00:17, 13 August 2019 (UTC)
•   SupportStudiesWorld (talk) 00:12, 13 August 2019 (UTC)
• Is there a good reason this property is specific to elections? Could it be formulated in a more general way? ChristianKl❫ 10:57, 13 August 2019 (UTC)
• Isn't it like that election are called by an entity defined in Constitiution or similar law? This should be called election reason. For example in Poland the reason could be inability to form government or cabinet stepdown but the election is always called by the President. It is also unclear wether we are talking about the function calling election or person calling election? Masti (talk) 09:24, 14 August 2019 (UTC)

### ordeal by

Done: ordeal by (P7209) (Talk and documentation)
Description manner of judicial practice by which the guilt or innocence of the accused was determined. trial by ordeal (Q40745) Item items about trials by ordeal e.g. Q43398278 subclasses of trial by ordeal (Q40745), linked to items e.g. dunking (Q4204228) not applicable trial of John Scot (Q43398278) → searching for Devil’s marks [Item to be created] trial of Jonet Coutts (Q43398389) → Bierricht (corpse bleeds) [Item to be created] trial of Elspeth Tod (Q43398629) → pricking (Q7242689) trial of Alexander Lyle (Q43403342) → dunking (Q4204228) --> Recorded in Survey of Scottish Witchcraft Database in judicial actions e.g. trial of John Scot [5] To add the ordeal by statement on the witch trial items in Scotland already created.

#### Motivation

I am working on importing elements of the Survey of Scottish Witchcraft database (1563 to 1736) with a student intern and there is good information on the types of ordeal employed during the trial process for the accused witches in the database (corpse bleeding, witch pricking, dunking in water, searching for the devil's mark etc.). The motivation therefore is that there is a gap in that Wikidata could model the different ordeal types which took place as part of historic judicial actions in a number of different cultures as covered in the Trial by ordeal Wikipedia page and could also include trial by combat as an ordeal also, which would serve historic datasets like this one but equally could also serve modern instances where someone has undergone such treatment. Stinglehammer (talk) 12:10, 13 August 2019 (UTC)

#### Discussion

Comment Just as an addendum, we have information on the 5 types of 'ordeal' the accused witches underwent. where ordeal is defined as "test conducted in order to let nature or God reveal the truth. It was technically distinct from torture, although many ordeals involved painful procedures".
1. Bierricht (corpse bleeds): corpse bleeds when touched by person who was guilty of the murder
2. Ducking: otherwise known as the water test. The accused person was put in water to see if they floated. If they sank they were seen to be innocent and efforts were made to rescue the suspect. If they floated they were seen to be guilty. This test was rarely used in Scotland.
3. Pricking: the body of the suspect witch was pricked with pins in order to find a Devil’s mark. Learned belief said that the Devil’s mark was left on the body of the witch after she or he had sealed a pact with the Devil. It was believed to be insensitive to pain. Often moles, warts or other visible skin blemishes were tested and shown to be Devil’s marks.
4. Searching: searching for Devil’s marks
5. Victim Fit: used in possession cases to identify the person causing the possession, victim had fit in presence of suspected persecutor.
The description seems to be very specific. How about the more general "manner of judicial practice by which the guilt or innocence of the accused was determined"? ChristianKl❫ 21:22, 13 August 2019 (UTC)
@ChristianKl: - Have amended the description accordingly. Stinglehammer (talk) 13:33, 14 August 2019 (UTC)
@Stinglehammer: Good, as far as the description goes. With the wider scope it seems like a different name for the label would be appropriate as well. Do you have any ideas about what might be a fitting label? ChristianKl❫ 11:08, 15 August 2019 (UTC)
@ChristianKl: Hmmm, I think trial type or similar would be useful to have if we go to a broader definition. ordeal by obviously is more specific instances that had unpleasant, often painful methods of determining guilt or innocence. Can see arguments for both. Stinglehammer (talk) 10:37, 17 August 2019 (UTC)

@Jura1: I find the creation in a state where the label doesn't really match the description problematic. ChristianKl❫ 07:13, 21 August 2019 (UTC)

• label and description seem to cover the usecases that were provided (see samples above) and the property seems to work out so far (already > 100 uses). --- Jura 21:22, 21 August 2019 (UTC)

### LINE BLOG user ID

Description user ID on LINE BLOG no label (Q29364694) External identifier Almost human (Q5) or group of humans (Q16334295), but there is some exception. [a-z0-9_]+ Momoko Sakura (Q1155646) → sakuramomoko HKT48 (Q47925) → hkt48 Q60988562 → aiuta_movie w:ja:Template:LINE BLOG Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. always incomplete (Q21873886) https://lineblog.me/\$1 Ameblo username (P3502)

#### Motivation

LINE BLOG is a famous blog service in Japan. 本日晴天 (talk) 06:24, 14 August 2019 (UTC)

#### Discussion

@ديفيد عادل وهبة خليل 2, Premeditated, 本日晴天:   Done: LINE BLOG user ID (P7211). − Pintoch (talk) 06:24, 22 August 2019 (UTC)

Under discussion
Description the number of logical cores of a CPU multithreading (Q1064412), related to, but not number of processor cores (P1141) Quantity property all natural numbers ( >=1) AMD Phenom II X6 1090T (Q66481199) → 6 AMD Ryzen Threadripper 2990WX (Q56062941) → 64 Core i5-760 (Q15223620) → 2 en:Multithreading (computer architecture) Add property on any item where number of processor cores (P1141) is used

#### Motivation

While working on CPUs, I saw that number of processor cores (P1141) is a thing. The property lists physical cores. This collects logical cores (physical cores + virtual cores = logical cores) --D-Kuru (talk) 16:56, 16 August 2019 (UTC)

#### Discussion

•   Support -- 18:18, 18 August 2019 (UTC)
Thanks for the note. It is somewhat of a specialised property for processors. But right now there is no clear option how this information should/could be added to the list. Since it's a key design element of modern CPUs I don't think it's an adequate solution to just skip it. --D-Kuru (talk) 20:47, 20 August 2019 (UTC)
•   Question Isn’t it just the multiplication of the number of cores by the number of « virtual core » per core ? And that last number is far more interesting as in SMT or other processor multithreading, this is the important value. If so it would be possible to describe each core (seems possible, see an example of core on wikichip ), describe it as a part of a processor,
< processor > has part (P527)   < skylake x >
quantity (P1114)   < 10 >
and
< skylake x > number of threads search < 2 >
(on the number of the wikipage it’s visible that the number of virtual cores on the processors with this core type is just the number of cores mulitplied by 2 … author talk page 20:41, 18 August 2019 (UTC)
Yes, for every physical core, there (usually) is a multiple of virtual cores for that (usually one virtual core per physical core). Here I tried to not only think about traditional x86 chips, but also for some other more specialised processors that may have an extra virtual core every other physical core. So some physical cores would be grouped for tasks that do not scale well on virtual cores. Other examples could be AMD's Bulldozer architecture where they combined two integer with one flop part into one 'module' (here it is even hard to say what the physical core actually is). As far as I know there is no mutithreading on these chip designes. However, there would be no option to say eg. 4 cores with 6 threads if we describe the logical cores by assigning every physical core X ammount of virtual cores.
Wouldn't has part (P527) actually overflow at some point when much more information (eg. IDs, Chache, etc.) is stored in there. There would be no need for any property since all could be collected in here.
--D-Kuru (talk) 20:33, 20 August 2019 (UTC)

### part number

Under discussion
Description the item's part number identifier (Q853614) External identifier property a string that contains numbers and/or letters AMD Phenom II X6 1090T (Q66481199) → HDT90ZFBK6DGR (OEM number), HDT90ZFBGRBOX (boxed number) AMD Ryzen Threadripper 2990WX (Q56062941) → YD299XAZUIHAF (OEM number), YD299XAZAFWOF (boxed number) Core i5-760 (Q15223620) → BV80605001908AN (OEM number), BX80605I5760 (boxed number, english version), BXC80605I5760 (boxed number, english version) en:Part number Add to every item for which a part number can be found

#### Motivation

While working on CPUs, I noticed that this property does not seem to exist. I had primarly CPUs in mind, but I'm sure there are a lot more items that have a part number in real life.
However, as shown in the example, there can be more than one part number for the same productname. So you have to be able to add some sort of referece to the information (eg. "OEM" or "boxed" or something like that) --D-Kuru (talk) 17:22, 16 August 2019 (UTC)

#### Discussion

Notified participants of WikiProject Properties   Notified participants of WikiProject Informatics Visite fortuitement prolongée (talk) 19:06, 18 August 2019 (UTC)

(in such a case we don’t have to discriminate between the user part number to the manufacturer one because it’s used by a user in a design)
Or … there is several numbers because there is subdesigns by the manufacturer of the same processor, in which case it may be possible to subclass the processor model item with fresh new items to reflect that, with their own properties and values to reflect the differences. author talk page 19:25, 18 August 2019 (UTC)
As far as I know the CPU type has a unique ID that changes under some conditions. The manufacturer is not such a condition - at least as far as I know. Since the ID is unique to every processor type I switched the datatype to external-id. It seems that the different numbers are more to indicate which segment of the global market is targeted. If the CPUs ID is ABC1 in the boxed version you will not find an appropriate CPU when it is labled ABC2. Even they are actually the same die under the hood. I don't think that a new item is really the route to go if there is just a different ID, but all other values stay the same. You don't create a new item for every version of some program, do you? --D-Kuru (talk) 20:58, 20 August 2019 (UTC)
Question Is this at all related to Global Trade Item Number (P3962)? See also the discussion on this old proposal. ArthurPSmith (talk) 17:50, 19 August 2019 (UTC)
Yes and now I would say. The part number is not the European Article Number. There is no bar code on the processor. But it's shares some properties since it's also a unique ID for every product. --D-Kuru (talk) 21:00, 20 August 2019 (UTC)

### CPUID

Under discussion
Description identification number of CPUs CPUID (Q1024235) External identifier property a string that contains numbers and/or letters AMD Phenom II X6 1090T (Q66481199) → 100FA0 AMD Ryzen Threadripper 1900X (Q56062710) → 800F11 Core i5-760 (Q15223620) → 106E5 en:CPUID Add to every item for which a CPUID can be found

#### Motivation

While working on CPUs, I noticed that this property does not seem to exist. --D-Kuru (talk) 18:13, 16 August 2019 (UTC)

#### Discussion

•   Comment Today I found out by accident that there already si a proposal for the same thing here. It was created back in early 2017, but it looks like it still isn't finished. --D-Kuru (talk) 19:53, 17 August 2019 (UTC)

Notified participants of WikiProject Informatics Visite fortuitement prolongée (talk) 18:52, 18 August 2019 (UTC)

•   Comment if it works as it should, the values should be unique, so I think we would want this to have external-id as datatype. --- Jura 17:00, 20 August 2019 (UTC)
Yes, The IDs should be unique. I changed the datatype --D-Kuru (talk) 20:23, 20 August 2019 (UTC)

### associated with

Under discussion
Description Used to describe a generic association of one item/concept with another, where we don't have a more specific property available Item Christmas cake (Q556060) → Christmas (Q19809) (qualifier subject has role (P2868) - "food associated with the festival") We Are the Champions / We Will Rock You (Q66008229) → News of the World (Q309021) (qualifier subject has role (P2868) - "single taken from this album") Handbuch zum Evangelischen Gesangbuch (Q53631328) → Evangelisches Gesangbuch (Q1381294) (qualifier subject has role (P2868) - "de:Kommentarwerk"/"en:Commentaries related to the work") Evangelisches Gesangbuch (Q1381294) → Handbuch zum Evangelischen Gesangbuch (Q53631328) (qualifier object has role (P3831) - "de:Kommentarwerk"/"en:Commentaries related to the work") Söderala church parish (Q10688470) → Söderala parish (Q10688474) (qualifier subject has role (P2868) - "administrative parish associated with, but not the same as, a religious parish") Reading (Q60578270) → Reading (Q7300456) (qualifier subject has role (P2868) - "constituency with the same name but different boundaries") King Arthur (Q45792) → Eildon Hill (Q3049397) (qualifier subject has role (P2868) - "legendary burial place") mangalsutra (Q2767663) → marital status (Q11920938) (qualifier subject has role (P2868) - "object used to signify") Will implement for administrative area relationships to begin with inspired by (P941), used by (P1535), based on (P144), influenced by (P737), different from (P1889), etc

#### Motivation

This is intended to be used to describe some way in which two items are related to each other, but where there isn't an existing property. The number of potential ways that something can be related/connected to another concept is very large. We have properties for many types of relationship (eg inspired by (P941), used by (P1535) or based on (P144)) but we are unlikely ever to create properties for all the ones we want to describe - some will be very specialised and only need to be used a few times.

My thought is that we can create a generic property to link two items together, with a mandatory qualifier to specify what exactly that relationship is (I've suggested subject has role (P2868), but perhaps a new qualifier property would be needed). The values would be items created to describe that specific form of relationship, allowing for queries. This is similar to relative (P1038)/type of kinship (P1039), which we use where one of the standard family properties like father (P22) can't cover the specific relationship.

Thanks to Moebeus & Salgo60 for some of the examples - see svwp and phab for more notes on parishes. Andrew Gray (talk) 14:43, 20 August 2019 (UTC)

#### Discussion

•   Strong support Nice! Moebeus (talk) 14:48, 20 August 2019 (UTC)
•   Support Ainali (talk) 14:54, 20 August 2019 (UTC)
•   Comment it seems to me that we already have a more specific properties for some of the samples above, notably "significant place", "different from", "main subject". --- Jura 15:04, 20 August 2019 (UTC)
• @Jura1: Good catch. I think there are certainly some overlaps - #6 would certainly fit nicely for "significant place", which I had forgotten was a property! And agree that "main subject" could work for #3 (perhaps with a qualifier to say "is a commentary" rather than any other kind of critical work). But some of the others definitely don't seem to fit in existing properties - eg #1, #2 or #7.
For #4/#5, fuzzy place relationships, using "different from" seems a bit awkward - I can see that it's a possibility, but it doesn't feel like quite the right relationship. It could be that the two items we want to connect aren't really confused by people, and the property description implies that they are. Andrew Gray (talk) 16:18, 20 August 2019 (UTC)
Replacing "main subject" with this seems like a terrible idea. I wonder if there isn't the risk of more similar lapses.
Depending on the names, I think you could have both "significant place" and "different from". We also have "facet of" which overlaps with this. For properties there is "see also", but for items, I vaguely recall that this wasn't thought of being a good idea. --- Jura 17:31, 20 August 2019 (UTC)
I think there are a lot of properties that overlap with this in various ways - in which case we should definitely use those properties. The idea here is to have a fallback option for when those don't work. Salgo60 - you suggested the Kommentarwerk example - is there a reason you thought "main subject" wouldn't work there? I think Jura is right that for that particular case, "main subject" seems more appropriate. Andrew Gray (talk) 18:14, 20 August 2019 (UTC)
•   Strong support - Salgo60 (talk) 17:08, 20 August 2019 (UTC)
•   Support Useful generic property to have. Jheald (talk) 17:21, 20 August 2019 (UTC)
•   Support I've long wondered why we don't have an item equivalent of see also (P1659) (which is for properties). But of course this should be limited only to the cases where there ISN"T an existing property that fits the relationship. ArthurPSmith (talk) 17:34, 20 August 2019 (UTC)
• Hard solid oppose per previous objections. Propose the properties that we should have in our ontology. --Izno (talk) 19:05, 20 August 2019 (UTC)
•   Support. If it turns out that we have (or later add) a more specific property, one can always update the item, but IMHO it’s good to be able to capture the relationship. - PKM (talk) 20:10, 20 August 2019 (UTC)
•   Oppose. Not sure about this. Existing properties such as facet of (P1269) are probably fine enough. Thierry Caro (talk) 22:43, 20 August 2019 (UTC)
•   Oppose I that case this is really a totally unspecified relationship, this will discourage people to propose properties if there is an alternate solution, and the qualifier to precise the relationship is an open gate for nonsense. Proposing a property is hard, creating an item or misusing one existing in a meaninless cryptic sense is really easy. We’ll end up with a mess. author talk page 06:21, 21 August 2019 (UTC)
I'll note that this exact argument, only in reverse, is used a lot when shooting down proposals for narrower properties. "We don't need this, we have a less specific property, just use qualifiers to specify it". The way I look at it, it's useful to have a kind of generic "supra-property" like this and use it when modelling: when and if we see a pattern emerge and there is significant volume, it'll be much easier to then propose something more specific and separate out the relevant property/item pairs, rather than starting with a property that is very/overly specific and that ends up being seldom used. There are quite a few of those. Moebeus (talk) 11:25, 21 August 2019 (UTC)
@Moebeus: I don’t dislike generic properties if they make sense on their own. For example instance of (P31) and subclass of (P279) are widely used on ontologies outside of Wikidata and Help:TomT0m/Classification can be well defined. This however needs carefulness. In such cases it can be counter productive to create to specific properties that are essentially the same relationships, but for two kinds of more specific items, this creates dispertion, a discrepancy of practices and models for the same thing. However, in this case, the exact same criticism as « two many properties and different ways to the same stuffs » is . Such a property is totally unspecified, and the probable usecase will be « OK, so I’ve this problem … so what do I do ? Oh, I have an excellent idea ! I’ll use the « relationship property with this qualifier ». And on another item, antother person on a similar case « Oh, I have an excellent idea, I’ll use the relationship property with that combined with that other qualifier ». Except there is no guarantee that a pattern will emerge or that the use will be consistent for similar cases, we already have such problems with current properties sometimes. People do something as they think it’s a good idea but it’s not always easy to decipher what their idea was in the first place. I think that models should be discussed at least a little bit. If their is a usecase, we should be able to find a not to bad solution and document it at least a bit. Such a generic property would in my opinion would have the same problems than too much specific one : too much solutions to express the same thing. So it’s not really a suprise that the argument is reversed, the solution is probably an equilibrium between the two, a compromise between regularity and flexibility/expressiveness. author talk page 11:45, 21 August 2019 (UTC)
•   Strong oppose The fact that example were proposed that can already be handeled with existing properties suggests the property would actually used in situations where our existing properties can already handel the situation. ChristianKl❫ 07:10, 21 August 2019 (UTC)
•   Oppose, per above and earlier arguments. --Yair rand (talk) 07:48, 21 August 2019 (UTC)
•   Oppose per the above. NMaia (talk) 21:44, 21 August 2019 (UTC)
•   Oppose I agree many of the examples are inappropriate since there is a more specific prop.
•   Support To all naysayers: how do you justify the existence of see also (P1659)? BTW, despite its definition, it's used to relate not only props but also categories. Eg route map (P15) is related to Category:Pages using Wikidata property P15 (Q28039620) and Q55283072
•   Support The fact that dc:relation and rdfs:seeAlso are some of the oldest props on the semantic web should tell us something
•   Support Quite often in source databases you have such kinds of relations, with no additional info about the nature of the relation. Isn't it better to capture the link, rather than dismiss it as unspecific? --Vladimir Alexiev (talk) 13:19, 22 August 2019 (UTC)
• If the goal is to import data that's already tagged with dc:relation or rdfs:seeAlso, why do you support a property that has neither of those names for it but a quite different one? If the goal is to copy data from an existing relation, then naming the same relation differently should be justified. ChristianKl❫ 17:40, 22 August 2019 (UTC)
• Can you provide examples of data sets that use either that you would want to import into Wikidata? ChristianKl❫ 17:46, 22 August 2019 (UTC)
• It does seem that see also (P1659) gets used currently in a constraint violating way. I don't think that needs justification, it rather needs a removal of the constraint violating uses. ChristianKl❫ 17:47, 22 August 2019 (UTC)

### Arnet Miner publication ID

Under discussion
Description ID of a publication in Arnet Miner Arnet Miner (Q56260244) External identifier article Big Data Analytics in Intelligent Transportation Systems: A Survey (Q66666226)=>5c2ea7c6df5b8c0b3ced3327 Personalized Recommendation of Photography Based on Deep Learning (Q66666956)=>5c2c7a6717c44a4e7cf30b95 Parameter Transfer Unit for Deep Neural Networks (Q66666960)=>5b1643998fbcbf6e5a9bc273 269402597 https://www.aminer.cn/archive/\$1 Yes Arnet Miner author ID (P5776)

#### Motivation

(Add your motivation for this property here.) GZWDer (talk) 20:49, 21 August 2019 (UTC)

### Open Science Framework ID

Under discussion
Description ID in osf.io Open Science Framework (Q18691678) External identifier person, projects, preprints and others [a-z0-9]{5} Ana Patricia Ayala (Q39381443) → wx9bf Maya B Mathur (Q66667493) → e9tg8 Philip N. Cohen (Q7184118) → 2u4tf Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. https://osf.io/\$1

#### Motivation

(Add your motivation for this property here.) GZWDer (talk) 21:44, 21 August 2019 (UTC)