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

Wikidata:Property proposal/Generic

 Before proposing a property Check if the property already exists by looking at Wikidata:List of properties (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 Change status=ready on template to attract the attention of a property creator. Creation can be done after 1 week 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 2017/02.

Generic properties

has code

Under discussion
Description code for Number character encoding (Q184759) none has code search < 0xE9 >  ; has code search < 0xE9 > codes for search < Q9995 > Ascii code (Par exemple: vérifier les autres propriétés afin d'être cohérent, collecter des données, automatiser un lien externe, etc.)

code for  Support as this is more generic. CC0 (talk) 18:51, 30 October 2016 (UTC)

•  Comment My gut feeling is that this would be better modelled as a claim on the item about the Unicode character, e.g.
< é > is encoded by search < Q935289 >
codepoint search < 0xE9 >
. Thryduulf (talk) 21:18, 16 November 2016 (UTC)
•  Oppose A Unicode character encoding like UTF-8, UTF-16, UTF-32 has over 100,000 assigned characters. Adding that many claims to an item is nonsensical (and is probably going to break the Wikidata software.) This proposal only really makes sense when you consider small character encodings like Latin1, but if the approach doesn't work for Unicode I don't think it is worth proceeding with. SJK (talk) 14:04, 10 January 2017 (UTC)
•  Oppose in the current suggested form as code (P3295)/encoding (P3294) and Unicode character (P487) are already being used on items which are instance of (P31) letter (Q9788) and this appears to be the saner approach as per @SJK:'s comment. Dhx1 (talk) 13:05, 8 February 2017 (UTC)

encodes

Under discussion
Description qualifier to link a code to the item of the character it encodes, if relevant. Number character encoding (Q184759) none see above example
Motivation

Compared to the other attempt, this property is restricted in domain and is in reverse sense : from character set encoding to the caracter, and not from character to code. This mean a letter can has as many code we want without being polluted by as many statements as there is character sets. There is also a qualifier to link to the item of the character if relevant. author  talk page 20:26, 12 October 2016 (UTC)

Discussion

Comment I imagine that the character set properties would get quite polluted themselves, most especially for a set like GB 2312 (Q1421973), Big5 (Q858372), Shift_JIS (Q286345) or KS X 1001 (Q489423). As for pollution of the items for the characters themselves--if anything, numerous codepages may end up sharing a codepoint for a single character, so the main risk is just a lot of qualifiers on a single code. When Wikidata-Wiktionary integration goes live, it may become much more beneficial to add character codes to items (especially Chinese characters) rather than to character sets. Mahir256 (talk) 01:57, 15 October 2016 (UTC)

Good point. Maybe another relationship should be used to minimize redundancy like "share/duplicates codes with/of", qualified by intervals of shared codes. Many ISO european standards charater sets shares a lot with ascii, that would avoid a lot of claims if we avoid duplicating all the shared codes with ascii. Do you know if there is a similar situation on oriental character sets ? Arabian and Cyrillic characters sets should be in a similar situation as there is about the same number of letters in arab alphabet and in latin one. Japan and China shares a lot of characters ... author  talk page 08:28, 15 October 2016 (UTC)

Support because it will be easy to search for the corresponding code point in different charsets. CC0 (talk) 18:57, 30 October 2016 (UTC)

1. I prefer the other way round, i.e. having a property to link characters with character encodings. Some character encoding sets can have many codes, e.g. UTF-8 encodes for all characters you can think of.
2. Number datatype only supports numbers in the decimal format, however, many codes are written down in hexadecimal. It might be easier to use hex here too, i.e. using string datatype. --Pasleim (talk) 11:43, 26 December 2016 (UTC)

Oppose I'm not sure if this is necessary a good fit for Wikidata. Unicode character (P487) already handles the mapping from characters to Unicode codepoints, although it would be far better if that was done as a number instead (e.g. "has Unicode codepoint" property) – P487 is very user-unfriendly when it comes to non-printing characters like Zero-width non-joiner (Q863569). But, as far as character encodings in general go – some of them are massive (with many thousands of code points) and can have quite complex encoding rules. How would you use this property with something like UTF-EBCDIC (Q718092)? It has over 100,000 code points (the same as Unicode) but it encodes them via complex rules as multi byte strings. But, does Wikidata really need to store this info? If we store the mapping of items to Unicode code points, then there are numerous software libraries (e.g. International Components for Unicode (Q823839)) which know how to map umpteen legacy character sets to/from Unicode. Trying to stuff that knowledge into Wikidata, while it might work for simple 8-bit character sets like ISO/IEC 8859-1 (Q935289), it won't work with complex multibyte character sets which are described as much by algorithms as by tables – it isn't Wikidata's job to store algorithms. SJK (talk) 14:20, 10 January 2017 (UTC)

@SJK: I think there is a misanderstanding here. I thought the existing property were to link the concept to its character. Not the codepoint. What did I miss ? Plus there is not ony unicode at sake, and the mere existence of a property does not imply we use it exhaustively and not case by case. These global opposal will mean we will have nothing overall for non unicode charset, hence we won't be able to store anything - other proposals have already been rejected. author  talk page 19:36, 10 January 2017 (UTC)
@TomT0m: You want Wikidata to say that "character encoding ISO/IEC 8859-1 (Q935289) (Latin1) encodes character É (Q9995) using the single byte E9". My point is that simple 8-bit encodings like Latin1 it is basically an arbitrary mapping from characters to single bytes which is easily expressed in a table. But for more complex encodings, e.g. multibyte encodings, it is much more complex. Do you want to say that in UTF-8 (Q193537) that character is encoded by two bytes C3 89? Well, then you can't really use "Number" for that property, you need something like a hex string. But why store that, when it is easy to programmatically derive it from the Unicode code point number using readily available libraries? Someone could write an external app which pulls the Unicode code point from Wikidata and then displays the encoding in various character encodings. Also, there are two other complexities to consider (a) UTF-8 is a stateless encoding so the same code point always encodes to the same byte sequence; but other multibyte encodings are stateful so which byte sequence a code point encodes to depends on the current encoding state; (b) what is considered a single character from a human perspective may actually be expressed in Unicode by multiple combining characters, so how will you model that? Basically, I think like this is a very complex area, and this proposal fails to properly take into account the complexities involved. SJK (talk) 20:39, 10 January 2017 (UTC)
@SJK: Well, this works for a lot of usecases, let's think of other ways to model more complex situations like unicode later. You'll notice that unicode has its own dedicated properties. I therefore don't think this is a valid argument not to do this. Let's focus on situation on there this works before - there is a lot of usecases and less complex character sets that can be modeled that way. I think we all know that unicode is complex. So ? ;) author  talk page 08:03, 11 January 2017 (UTC)
@TomT0m: I think if this is going to be done, I think at a minimum (1) the "has encoding" property should be on the character not on the character set (2) it should have type String with a regex constraint of [0-9A-F]{2}+, not type Number (3) it should have a compulsory qualifier "in character set" of type Item pointing to the character set in which this character has this encoding. The reasons for this is (1) a single encoding may contain many thousands of characters, whereas there aren't many thousands of encodings, so better 1 "has encoding" property on each of a thousand characters than 1000 properties on the encoding item (2) for proper generality, the encoding should be a byte string not a number. For example, the Greek letter Ω (Q9890) has UTF-8 encoding CEA9 (two bytes). While you could strictly speaking display that as the number 0xCEA9 or 52905 decimal, absolutely nobody does that. So, I'd suggest you might want to consider reformulating your proposal along the lines I suggest. SJK (talk) 03:18, 15 January 2017 (UTC)
•  Oppose with the suggested domain of character encoding (Q184759). If however the domain of this property proposal is changed to natural number (Q21199) then I think a case may exist for this property proposal (perhaps with another name?). Dhx1 (talk) 13:07, 8 February 2017 (UTC)
• @Dhx1: I am unconvinced that natural number (Q21199) is the right domain. Take for example em-dash (Q10941604), which has Unicode codepoint U+2024 and UTF-8 encoding E28094. Are you saying that 8228 (Q19261720) (which is decimal for hex 2024) should have a property pointing to em-dash (Q10941604)? Or, similarly, a new item to represent the natural number 14844052 (which is decimal for hex E28094) with a property pointing to em-dash (Q10941604)? I think the domain should be character (Q32483) or character (Q3241972) not natural number. Also, the property data type should be string rather than number or item. This is because, while it might be strictly speaking mathematically correct that E28094 is equivalent to 14844052, no one ever writes UTF-8 in that way. E28094 is not a single number, it is actually a sequence of 3 8-bit numbers. Even though mathematically any sequence of integers is equivalent to one single integer, humans don't usually think that way outside of certain limited mathematical contexts (such as Gödel numbering (Q1451046)). SJK (talk) 21:11, 8 February 2017 (UTC)

strength

Under discussion
Description the concentration or strength of a product, related to the amount or proportion of active ingredient(s) Number products, medicines, qualifier for the proposed legal status (medicine) property non-negative numbers milligrams, grams, percentage, proof, millilitres, units of concentration, probably others ibuprofen (Q186969) → 200 milligram (Q3241121) [see below for more detail] This is required for correct modelling of medicine sales restrictions, but is also intended for more general application minimum explosive concentration (P2204), minimal lethal concentration (P2710), lower flammable limit (P2202), ceiling exposure limit (P2405), lowest-observed-adverse-effect level (P2718), short-term exposure limit (P2407), alcohol by volume (P2665) and other specialised properties relating to these
Motivation

In discussing how to model restrictions on medicine sales at Wikidata:Property proposal/legal status (medicine) it has become clear that we have no way of expressing currently the strength of a medicine. For example in the UK ibuprofen (Q186969) 200mg strength can be bought in a supermarket but a pharmacist can sell 400mg strength. quantity (P1114) is not suitable for this as that will be used to express restrictions like the number of tablets that can be legally purchased (in the UK acetaminophen (Q57055) can be bought in packs of 16 tablets from a supermarket but packs of 32 from a pharmacy for example). We have a alcohol by volume (P2665) property specifically for the strength of alcoholic beverages and several very specialised concentration properties but nothing for other products that have varying strengths (e.g. tobacco, glue, washing up liquid, etc). Thryduulf (talk) 14:28, 6 November 2016 (UTC)

Discussion
• Those are all mass (P2067) units so why not use that property for this? ArthurPSmith (talk) 21:46, 7 November 2016 (UTC)
• My first reaction is that I would expect mass (P2067) to be the mass of the product not the quantity of active ingredient(s) which can be measured by mass (relative or absolute), volume (relative or absolute), concentration, or combinations of these (and possibly other units too). Thryduulf (talk) 18:59, 8 November 2016 (UTC)
• How do other ontologies call the relationship between ibuprofen (Q186969) and 200 milligram (Q3241121)? I wouldn't want to create this property the proposed way without investigating how the relationship is modeled elsewhere. We should only invent a new way to model this relationship if there's an argument made that existing ways of modeling the relationship aren't appropriate for Wikidata and currently I don't see such an argument made here. ChristianKl (talk) 20:27, 8 November 2016 (UTC)
• I've not seen any other ontologies that model this, and nobody has linked to any in the months of discussion leading up to this proposal. In what other ways could it be modelled? Thryduulf (talk) 13:05, 10 November 2016 (UTC)
• I don't think "nobody cared to do the research" is a good criteria for property creation. I look at how DrugBank models this property and it also uses strength (https://www.drugbank.ca/drugs/DB01050), so strength seems okay. ChristianKl (talk) 10:55, 15 November 2016 (UTC)
• Is this property only supposed to be used as a qualifier? ChristianKl (talk) 20:28, 8 November 2016 (UTC)
•  Support ok, I've been thinking about this, I think it does make sense to have a dedicated property for this. However, the name needs to be more specific - maybe "medication strength per dose" ? ArthurPSmith (talk) 16:45, 15 November 2016 (UTC)
• Strength per unit, perhaps? For use as a qualifier for modelling medicine sales restrictions both a minimum and maximum strength property would seem to be required though? Domswaine (talk) 19:45, 05 February 2017 (UTC)
•  Oppose unless this property is: (1) named "concentration", (2) used as a qualifier on has part (P527) (or perhaps other more specific properties better suited to chemistry) and alongside additional qualifiers such as solvent (P2178), (3) has an allowed domain of mixture (Q169336) (including subclasses which currently need to be reorganised), (4) has units constrained to items which have measured physical quantity (P111) concentration (Q3686031)). This would make the property far more generic and allow specification of not just the "strength" of medicines, but also the recorded pollution levels in cities (particulates in parts per million, etc), concrete suspensions and many other aspects of chemistry. Dhx1 (talk) 13:55, 8 February 2017 (UTC)

Notified participants of WikiProject Chemistry for expert advice. Dhx1 (talk) 13:57, 8 February 2017 (UTC)

•  Oppose. As Dhx1 says: better named 'concentration', or maybe 'dose', 'quantity per unit'. While 'strength' may be the common wording in medicine context, especially spoken, it should be defined being a physical quantity with correct dimensions (in general: quantity = number × dimension; e.g., speed = 40 km/h). In the example "200mg" the dimension appears to be mg, but is understood and implied to be mg/unit. -DePiep (talk) 14:17, 8 February 2017 (UTC)
•  Comment A property "concentration" can make sense and can be used for other properties like pH for organic compounds (solvent or solid) when diluted in water to measure a pH. Snipre (talk) 17:09, 8 February 2017 (UTC)
•  Oppose Useful information but not here. I don't see how this would be meaningful as a property of the compound especially without any context. Yes there are regulations and standards for formulations depending on country, but really it is completely arbitrary and can easily change in time and space. And the formulation and the prescription arn't necessarily related, for example with pain relief medication, one may need to gradually ramp or taper their dose by dividing or multiplying pills. Aswell the dose depends on what the drug is indicated for such as bupropion or trazodone. I suggest making a page for the formulation than use something like ingredient property with a quantity attached to it. See my comment on Wikidata:Property proposal/National Drug Code for more detail. Devon Fyson (talk) 09:44, 9 February 2017 (UTC)
•  Oppose. There is no explanation how the "correct modelling of medicine sales restrictions" will be achieved using this property. What's more, adding this property, as proposed, to compounds would be wrong, because it's not a strength of a compound but a medicinal formulation. The units should be e.g. miligrams per dosage form in some cases but concentration in other. Wostr (talk) 12:17, 9 February 2017 (UTC)

Notified participants of WikiProject Medicine, @Wostr: This property was initially proposed to qualify the legal status of medicinal drugs (P3493) - e.g. simvastatins can be bought over the counter in pharmacies in the UK where the strength of each unit/tablet is less than 10mg, stronger doses are only available on prescription. Domswaine (talk) 19:13, 09 February 2017 (UTC)

• @Domswaine:, Yes, that's something I understand from the proposition. What I don't understand is the exact relation between pure compound element, formulation element, proposed property, legal status (medicine) (P3493), and maybe other necessary properties/qualifiers. The example given in the proposition tells nothing and is wrong. In other words, what is the "correct modelling of medicine sales restrictions"? Wostr (talk) 20:15, 9 February 2017 (UTC)
• @Wostr: I imagined an applies to (min/max) strength property (of active ingredient) and the applies to territorial jurisdiction (P1001) property as qualifiers to the legal status of medicinal drugs (P3493) property. Domswaine (talk) 20:33, 09 February 2017 (UTC)
• Okay, but how do you want to indicate min or max strength with only one property (strength)? I think there's a reason why we have e.g. lower and upper explosion limits properties, not only one property (explosion limit). From what you're saying, I can imagine a relation:
Drug element (Q....)
I don't know where the max/min is needed here, but the problem is we don't have medical fomulations as different elements in WD, and I don't think we should. The other option is to have such relation in chemical compound elements (like in ibuprofen (Q186969)), but this would be wrong, as strength is not a property of chemical compound. Wostr (talk) 20:17, 15 February 2017 (UTC)
•  Comment I am leaning to oppose, but... this property is not one of a compound like ibuprofen, but of products (as the proposal suggests). But I question if we really want to have every formulation of products in the database. That's pretty unbounded, different for many countries, and likely volatile (companies change products, new vendors arise, etc, etc). But if this community decides that medicinal products are considered good to have in Wikidata, then it makes sense to have this property. --Egon Willighagen (talk) 10:19, 11 February 2017 (UTC)
• BTW, the example links strength to a compound, and that I definitely  Oppose. But I think the given example in not in line with the given "domain". --Egon Willighagen (talk) 10:21, 11 February 2017 (UTC)
• @Wostr: Agree dose may be better wording. As the legal status is dependent on the strength/dose (active ingredient in mg, per day), an 'applies to max strength/dose' and an 'applies to minimum strength/dose' property seem necessary to qualify the legal status, for certain medications. Eg. simvastatins can be purchased (in a pharmacy) without the need of a prescription where dose is less than 10mg per day, otherwise a prescription is required. Domswaine (talk) 16:57, 16 February 2017 (UTC)

time of the day

Under discussion
Description time of the day in hours and decimals (1h15' pm > 13.25). Can be used as qualifier or statement. Add another qualifier to specify timezone, if not local time. Number August 2016 Central Italy earthquake (Q26689701) → point in time (P585) 24 August 2016 qualifier "time of day": 01.69166666667
Motivation

Currently, there is no other way to specify this. If ever a better solution becomes available, the data could be converted.
--- Jura 22:42, 1 December 2016 (UTC)

Discussion
•  Comment Please complete above as needed.
--- Jura 09:23, 1 December 2016 (UTC)
•  Oppose I fear that two many people would enter for "1h15" 1,15. As a result the data couldn't be trusted. ChristianKl (talk) 12:30, 2 December 2016 (UTC)
• It seems to work for other properties. You'd rather do three separate ones?
--- Jura 12:55, 2 December 2016 (UTC)
•  Comment. Let's just create an item for any specific time of the day, minute by minute. Then change the datatype in this proposal to 'item'. Thierry Caro (talk) 18:44, 2 December 2016 (UTC)
• It's more parsimonious to create two properties, minutes of hour and hour of day. But it does not seem to be a problem to create 24*60 items and it's easier to autocomplete this. Maybe times 3600 would be more problematic :) author  talk page 13:14, 7 December 2016 (UTC)
Comment I just created a QuickStatement script to create the items about minutes : User:TomT0m/minutes. I'd like a review before batch creating it and taking ideas about what could be added. author  talk page 14:16, 7 December 2016 (UTC)
@TomT0m: I like the idea. My comments are, it is strange in English to write "12h00 AM", use of "h" like that is more of a French thing. Secondly, many English speakers, including myself, would actually prefer to use 24 hour time (e.g. "00:00" not "12:00 AM"). I suggest that ISO 8601 (Q50101) is a valid format in all languages (English, French, whatever), hence the labels in both English and French should be "00:00" through "23:59". SJK (talk) 08:43, 12 February 2017 (UTC)
Also I am a bit confused by "P31 Q27972125 P279 Q7727". If type of daytime minute (Q27972125) is meant to represent "minute of the day", better just call it that, and make it a subclass of minute (Q7727). Then all your script needs is "P31 Q27972125", rather than both a P31 and a P279 on every item. SJK (talk) 08:49, 12 February 2017 (UTC)
•  Support Much needed and general enough to be very useful. Ainali (talk) 07:52, 3 January 2017 (UTC)
•  Comment I think the best way is to enable us to specify time of the day and time zone at time datatype. According to Special:ListDatatypes, time datatype probably saves these internally. --本日晴天 (talk) 06:58, 8 January 2017 (UTC)
{{Ping|本日晴} Not the same. It's a specific point in time, whereas here we'll be able to specify stuffs like "everyday at noon" or every year the 25th of december. A specific timestamp allows only to specify a specific point in time (with precision). author  talk page 19:24, 8 January 2017 (UTC)

Hour and minutes number

As a follows up to the previous proposition of using item datatype to represent a pair (minute, second) in a day, I'd like to add two property proposal that aims to describe those items : "minute number in the hour" and "hour number in the day".

hour number in the day
Under discussion
Description the number of the hour in the usual 24h day. from 0 for the midnight hour to 23 for the hour before midnight Number Q27972125 [0, 23] none < 1h23 > number of hour in day search <  1 > < 1h23 PM > number of hour in day search <  13 > will be automatically filled
minute number in the hour
Under discussion
Description the number of a minute in a minute of the day item. From 0 to 59 (fr) – (Please translate this into English.) Number Q27972125 [0, 59] < 1h23 > number of minute in the hour in day search <  23 > < 1h23 PM > number of number of minute in the hour search <  23 > will be automatically filled

@Jura1, Thierry Caro, ChristianKl: author  talk page 18:04, 7 December 2016 (UTC)

This looks better, but I would prefer a native implementation that adds a new datatype.  Weak support ChristianKl (talk) 21:01, 10 December 2016 (UTC)
•  Oppose per ChristianKl's suggestion. ~ 12:42, 21 December 2016 (UTC)
• @ChristianKl, NMaia: Easier to implement and easily migrate later. But as in my previous comment there is chances that an extension of the "time" datatype will only allow to specify more precise timestamp, and not stuffs like "noon hour is 12:00" that recurs other time. author  talk page 19:26, 8 January 2017 (UTC)
•  Oppose Not very keen on this, would much rather see a native data type for it. Furthermore, in the absence of a native data type, would rather see a single property of string data type with a regex e.g. ([01][0-9]|2[0-3])(:[0-5][0-9])? (but, can the Wikibase software enforce the regex at data entry time??? And display some hint text to the editor explaining the expected format, since most people can't be expected to understand regexes?). SJK (talk) 08:38, 12 February 2017 (UTC)
Actually, I like better your other proposal, of a single property, with Item as a datatype, and then create 3600 items, one for every minute of the day. That is probably even better than a string. SJK (talk) 08:46, 12 February 2017 (UTC)
However if we need to specify seconds we need 86400+1400=87800 items.--GZWDer (talk) 17:15, 18 February 2017 (UTC)

screenshot image

Under discussion
Description Screenshot of the software screenshot (Q208594) Commons media file en:Template:Infobox software: "screenshot" software (Q7397) Trisquel (Q1588573) → Trisquel 7.0 LTS screenshot.jpg
Motivation

This was discussed before, but it didn't move forward due to low participation and some dissent. I believe this property is necessary to ensure that our data is as structured as possible. image (P18) is very vague, and machines cannot parse exactly the relationship between the image and the item, so we should use image (P18) only when other, more specific properties do not apply. We have several other, more specific properties, so I don't see why this one wouldn't be valid too. ~ 13:43, 20 December 2016 (UTC)

Discussion
•  Support Because having the property makes it easier for Wikipedia templates to interact with Wikidata. ChristianKl (talk) 10:57, 24 December 2016 (UTC)
•  Oppose I'm not really sure what else would be in P18 for software. For logos, there is already a specific property.
--- Jura 11:35, 24 December 2016 (UTC)
• Take this example: File:ThinkPad X60 Series with Libreboot.jpg. ~ 19:24, 24 December 2016 (UTC)
• It's a screenshot ;)
--- Jura 14:31, 3 January 2017 (UTC)
• Well, you can always add a qualifier to describe the exception. Most p18 for people are photographic portraits. There are a few exceptions, it could be drawing, sculpture etc. Still, there isn't much use in creating a property "portrait photo".
--- Jura 14:42, 3 January 2017 (UTC)
•  Support (P18 for software could also be an image explaining how the software works.) Ainali (talk) 07:55, 3 January 2017 (UTC)
•  Oppose For most software items screenshot is the only image they need. —putnik 10:46, 13 January 2017 (UTC)
•  Oppose The image (P18) of software is naturally a screenshot. —Wylve (talk) 09:54, 27 January 2017 (UTC)

Legend

Under discussion
Description Commons dataset containing symbols used in formula or diagram String /.*\.tab\$/ Pythagorean theorem (Q11518) → defining formula (P2534) → Sandbox/Ignatus/Pithagor.tab Wikimedia Commons (Q565) Qualify all defining formula (P2534) in an appropriate way https://commons.wikimedia.org/wiki/data:\$1 Existence of Commons page must be checked
Motivation

Currently, the property defining formula (P2534) contains inconsistent information: formulae without a legend are just pretty pictures with, formally, no direct meaning. Some parameters of formulae don't have any standard symbols or have multiple traditions, each of which is not comonly known. For data consistency, we need to make legends for them, as well as for diagrams. Current use of has part (P527) is definitely a bad choice - it must describe object, not its formula; then, symbols describe item properties (${\displaystyle a}$ in Pythagorean theorem (Q11518) means length of catet, not catet) and often are too special to have not a natural language definition. And we don't even have multilingual texts here for this purpose yet; and the overall data structure to qualify a formula seems to need qualifiers on qualifiers which is not even planned. Luckily, now we can store datasets on WM Commons which can be accessed from wikis with mw.ext.data.get("Example.tab"). Example of such a dataset for ${\displaystyle a^{2}+b^{2}=c^{2}}$ I've made in commons:Data:Sandbox/Ignatus/Pithagor.tab Ignatus (talk) 19:32, 28 December 2016 (UTC)

Discussion
• @Ignatus: Note that formatter URLs only work with external-ID datatype properties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 28 December 2016 (UTC)
•  Comment Datatype would probably need to be whatever comes out of phab:T151334.
--- Jura 13:17, 29 December 2016 (UTC)
•  Comment Personally, I prefer if the links would be kept in Wikidata. (Previous discussion at Wikidata:Project_chat/Archive/2016/12#Symbol_definitions_with_math_datatype).
--- Jura 13:17, 29 December 2016 (UTC)
•  Support I like this approach. It would be nice if there was some way to more tightly integrate the commons tables with wikidata though... ArthurPSmith (talk) 16:45, 29 December 2016 (UTC)
• I don't quite see how this would be happening anytime soon.
--- Jura 16:49, 29 December 2016 (UTC)
•  Oppose it's not really clear how they should remain in sync either.
--- Jura 17:03, 2 January 2017 (UTC)
•  OpposeGiven that this is about the commons integration, I think we should wait for more developmental work to be done instead of trying to fix the subject witht he available tools. ChristianKl (talk) 19:05, 22 January 2017 (UTC)

Related Categories

Under discussion
Description تصانيف متعلقة بهذا العنصر (ar) – (Please translate this into English.) Item Wikimedia category (Q4167836) website account on (P553)

I created these proposal after the discussion in previous proposal Wikidata:Property proposal/Category_for_people_deaths_by_this_disease and I think these is the better way.

Another example can be like :

Given these changes, I'd try to reformulate one along this.
--- Jura 07:56, 8 January 2017 (UTC)
•  Oppose per my comments in the previous thread linked; and additionally, this is not structured data. --Izno (talk) 19:46, 4 January 2017 (UTC)
•  Oppose per Izno; and per previous discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:24, 6 January 2017 (UTC)

Number of Supporters, Opponents and Absents

Under discussion
Description Number of Supports in a vote Support (Q340406) Number "for" in en:template:Infobox UN resolution United Nations Security Council Resolution 687 (Q2355527) → 12 I plan to add the data to wikidata using Harvest Templates, and then to connect this property to he:תבנית:החלטה של האומות המאוחדות
Motivation

I want to make infoboxes easier to fill in Mikey641 (talk) 18:16, 6 January 2017 (UTC)

Discussion

Comment There is 2330 United Nations resolutions, so it could be interesting to create and add in UN resolutions templates, like Infobox UN resolution and Ficha de resolución de la ONU. I searched in United Nations resolutions items and anyone have a similar property to show how many votes support or oppose the resolution, and how many abstentions were there. I am trying to participate more in talks about property so I prefer to read what other users think about it, because maybe I am forgetting something. But, summarily, create a property for that seems a good idea; I imagine that the property could be "Number of Supporters, Opponents and Absents" and then use qualifiers like "for", "against", "abstention", or whatever that might be necessary. Regards, Ivanhercaz | Discusión 18:53, 6 January 2017 (UTC)

What I originally ment was to add one property for "Supporters" one for Opponents and one for Absents but using qualifiers is actually a great idea. We can call the property "Number of votes" and then add the qualifiers.--Mikey641 (talk) 19:06, 7 January 2017 (UTC)
@Mikey641: Could you be specific what property and values you are proposing to use as qualifier? An existing property or are you proposing a new one? SJK (talk) 03:23, 15 January 2017 (UTC)
We have votes received (P1111) and a group of other election-related properties, which I guess we can use for this. But they are not used in a consistent way, as far as I can see. -- Innocent bystander (talk) 19:34, 18 January 2017 (UTC)

Comment It might be more useful to actually name the actual members (member states in the case of UN resolutions) who voted in support, opposed or abstained. The three properties should be expanded to legislative bills in general as well. Because members of legislatures are (usually) notable enough using items as opposed to number for datatype should not be an issue. —Wylve (talk) 10:02, 27 January 2017 (UTC)

But it could be a tiresome work to create items for them all, if they do not have articles on WP. And in many cases, we probably know very little about them. We may know their names and which political party they represents, and not much more. -- Innocent bystander (talk) 20:14, 28 January 2017 (UTC)
It might take a long time and will never be complete, but if we want comprehensive data then it's better to know who voted. But also this: if the legislators themselves are not notable enough for Wikipedia, then I doubt the bill/resolution will also exist on Wikipedia. —Wylve (talk) 11:26, 29 January 2017 (UTC)
Maybe true, but we also have to take care of the scalability of our systems here. TAke one step back and look at elections in general. Take sv:Landstinget Västernorrland as an example. There you see numbers about every general election since 1916. The statistics we have about the 2014 election is huge. We know how people voted down to city block (Q1348006)-level. But in the 1916-election, we do not know the names of the legislators, we do not know how many votes they got. In the majority of these elections, we only know how many seats of the legislative body had people representing national political partys. We can therefor not even separate "independent" from "local political partys". The difference between 2014 and 1916 is not how "notable" these legislators are, it is a matter of how much information has been stored. -- Innocent bystander (talk) 13:54, 29 January 2017 (UTC)
Of course the availability of data does not determine the notability of entities. In cases where there is insufficient data, we can always use the unknown value or leave it blank until better sources emerge. Ultimately Wikidata decides what and which kinds of data gets imported. My point of view is that some data is better than no data. We should provide a schema for 2014 data even if there is no 1916 data for the same claims. —Wylve (talk) 14:04, 29 January 2017 (UTC)
In this example, you see that every election from 1916 to 2014, has been regarded as "notable" for a section of an article in WP. But I do not know if one single legislative in Västernorrland has an WP-article. Naturally, since they are ~100 every three to four years during 100 years, at least some of them have an article. But I do not know where they can be found, since we have no category for legislatives in Västernorrland. -- Innocent bystander (talk) 15:10, 29 January 2017 (UTC)
I understand your point. Maybe we can have three separate properties for supporting, opposing and abstaining votes to indicate the number of votes, and another three properties to indicate the actual legislators with item type. But I would not use votes received (P1111), as that is reserved for elections not bills and resolutions. —Wylve (talk) 16:47, 29 January 2017 (UTC)

label in locative

Under discussion
Description locative form of the label in the language locative case (Q202142) Monolingual text Wrocław (Q1799) → pl:"Wrocławiu"
Motivation
• Not much. See below.
--- Jura 12:36, 6 January 2017 (UTC)
Discussion
Why not make something like female form of label (P2521) and call it "label in locative"? My home language (sv) has no casus at all, so I feel I am on very thin ice here! -- Innocent bystander (talk) 13:10, 6 January 2017 (UTC)
Done I think the property might be more of an advantage for speakers of languages without a locative. Depending on the language even for native speakers it can be helpful, as forms don't always follow simple rules.
--- Jura 14:20, 6 January 2017 (UTC)
•  Oppose We don't need a new property to be able to add aliases, so I don't see why this is so urgent that we need a temporary property for it and can't wait until we have Wiktionary support. - Nikki (talk) 18:29, 11 January 2017 (UTC)
@Nikki, Jura1: et al. Is Wrocław (Q1799) a typical topic in Wiktionary? -- Innocent bystander (talk) 19:38, 11 January 2017 (UTC)
@Innocent bystander: Yes, see wikt:en:Wrocław. Proper nouns like that are still words and still have linguistic information associated with them (etymology, pronunciation, audio, gender, declensions, derived words, translations, etc) so there is no reason to exclude them. - Nikki (talk) 20:17, 11 January 2017 (UTC)
One advantage with that would maybe be that "Wrocław", "Wroclaw" and "Breslau" can have different locative. -- Innocent bystander (talk) 08:37, 12 January 2017 (UTC)
What would be the disadvantages of storing the information in a property until Wiktionary offers that (e.g. in 2018)? Aliases aren't really structured.
--- Jura 07:54, 12 January 2017 (UTC)
If this needs to be added now, it's your job to convince us why it's so important that it can't wait. There have already been various other things we didn't add because they belong in Wiktionary, many of which had better justification for why we should have them. Converting things is inherently disruptive. You might remember how much arguing was involved with introducing external identifiers, that was a trivial change in comparison. - Nikki (talk) 00:02, 13 January 2017 (UTC)
Well, I did most of the work for that conversion (at least, what wasn't done by devs) and a few others. Generally, I think I can say that I follow through with my proposals without creating much of cleanup for others. I don't think there is much disruption if it was made clear beforehand. Personally, I'd rather add it this year than next year.
--- Jura 08:46, 14 January 2017 (UTC)

signed form

Under discussion
Description manually coded form of this language Manually coded language (Q1808730) Item |sign= in en:template:Infobox language languages
Motivation

Fills a template need. ~ 18:04, 11 January 2017 (UTC)

Discussion

Higher

Under discussion
Description For awards granted by countries or other bodies that maintain an order of precedence for decorations, the next highest award, if any. Item Higher in en:Infobox_military_award / СтаршаяНаграда в ru:Карточка награды award (Q618779) Navy Cross (Q833465)→ Medal of Honor (Q203535), Order of the Patriotic War (Q312496) → Order of Alexander Nevsky (USSR) (Q11798924)
Motivation

I suggest a new property that can be used in the items of the awards have regulated the order of precedence ShinePhantom (talk) 10:21, 13 January 2017 (UTC)

Discussion

Lower

Under discussion
Description For awards granted by countries or other bodies that maintain an order of precedence for decorations, the next lowest award, if any. Item Lower in en:Infobox_military_award / МладшаяНаграда в ru:Карточка награды award (Q618779) Medal of Honor (Q203535)→ Distinguished Service Cross (Q833376), Air Force Cross (Q407132) and Navy Cross (Q833465). Order of Alexander Nevsky (USSR) (Q11798924) → Order of the Patriotic War (Q312496)
Motivation

I suggest a new property that can be used in the items of the awards have regulated the order of precedence ShinePhantom (talk) 10:21, 13 January 2017 (UTC)

Discussion

Muzzle velocity

Under discussion
Description the speed of a projectile at the moment it leaves the muzzle of a gun muzzle velocity (Q920165) Number velocity at en:Template:infobox weapon weapon number m/s AK-47 (Q37116) → 715m/s probably
Motivation

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

Discussion
•  Oppose The notable variables for muzzle velocity are length of the barrel and the characteristics of the ammunition. How would this property allow both a weapon and a very specific manufacture of ammunition to be defined? One suggestion is to have a item:weapon property:fires_ammunition item:ammunition triple with a qualifier of muzzle velocity (Q920165). Or perhaps the qualifier should be Muzzle energy (Q1410940) instead? Dhx1 (talk) 12:34, 8 February 2017 (UTC)

rate of fire

Under discussion
Description the frequency at which a specific weapon can fire or launch its projectiles Rate of fire (Q753454) Number rate at en:Template:Infobox Weapon weapon number rpm M198 howitzer (Q1042260) → 4rpm probably
Motivation

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

Discussion

firing range

Under discussion
Description firing range of weapon Number |range= in en:Template:Infobox Weapon weapon number metre (Q11573), kilometre (Q828224) QJY-88 (Q6458018) → 1000m probably
Motivation

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

Discussion
•  Comment "firing range" is often the term used to describe a place where one can fire guns at targets. I think "weapon range" or perhaps "deadly range" would be a better name for this property. ArthurPSmith (talk) 19:22, 17 January 2017 (UTC)
•  Support with a better name, per Arthur. Added "kilometre" as an allowed unit, for artillery. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 17 January 2017 (UTC)
•  Oppose in the current form because the range of a weapon has many variable factors including the ammunition type, test conditions (weather, firing position), etc. For example, how would someone determine the range of a boomerang (Q131536)? I thought about whether determination method (P459) could be a mandatory qualifier to determine how the range was calculated, but am not aware of standards which may be used to test the range of weapons. Are there standards which could be referred to with a determination method (P459) property? If so, I'd be happy to change this vote to one of support as a testing standard should remove the variable factors. Dhx1 (talk) 12:23, 8 February 2017 (UTC)

international standard

Under discussion
Description international standard of the given item. Add "ISO standard" as an alias and change the existing ISO standard (P503) to "ISO standard number" (also see deletion of this property at Wikidata:Properties for deletion) international standard (Q1334738) Item |standard= in en:Template:Infobox media any standard Video CD (Q321259) → White Book (Q4019519) No
Motivation

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

Discussion

Identifiers.org namespace

Under discussion
Description namespace of given collection at Identifiers.org, define in the MIRIAM Registry (Q16335166) Identifiers.org (Q16335163) External identifier database string ChEMBL (Q6120337) → chembl.compound http://www.ebi.ac.uk/miriam/main/collections/ http://identifiers.org/\$1/ Probably
Motivation

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

Discussion
Comment Hmm, should this be a statement on the database/collection item, or on our identifier properties? I think it would be better to directly link our identifier properties to the corresponding identifiers.org value. ArthurPSmith (talk) 16:41, 18 January 2017 (UTC)

MIRIAM Registry identifier

Under discussion
Description identifier of a database in MIRIAM Registry MIRIAM Registry (Q16335166) External identifier database \d{8} ChEMBL (Q6120337) → 00000084 http://www.ebi.ac.uk/miriam/main/collections http://www.ebi.ac.uk/miriam/main/datatypes/MIR:\$1 probably
Motivation

Unclear whether "MIR:" should be part of identifier. GZWDer (talk) 14:20, 18 January 2017 (UTC)

Discussion
Comment see also the proposal for Wikidata:Property proposal/Identifiers.org namespace ArthurPSmith (talk) 16:43, 18 January 2017 (UTC)

only valid for subset

Under discussion
Description This should only be used as a qualifier. It denotes that the statement isn't true for all instances but only for a subset. Item Rectus abdominis muscle (Q275150) innervated by (P3189) Sixth intercostal nerve (Q27058097) → this property → Unknown value
Motivation

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

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

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

Enciclopedia Italiana

Under discussion
Description identifier for the Enciclopedia Italiana on Treccani website Enciclopedia Treccani (Q731361) External identifier "1" in w:it:Template:Enciclopedia Italiana generic [a-z0-9-] Germany (Q183) → "germania" http://www.treccani.it/enciclopedia/\$1_(Enciclopedia-Italiana)/ Enciclopedia Treccani ID (P3365)
Motivation

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

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

Discussion
•  Comment if I understand correctly, these id's can be entered now using Enciclopedia Treccani ID (P3365) but for many of items we could end up with 2 (or 3 or more?) id's? I'm not sure this is really a problem, I think the intent with Enciclopedia Treccani ID (P3365) was to cover everything on treccani.it. ArthurPSmith (talk) 20:04, 25 January 2017 (UTC)
The fact is that they are two completely different works. Like for the DBI, for example, we have a distinct property, even if it is hosted always in treccani.it. Obviously it is technically possible to insert all the different encyclopedias under the same property, but I think the most-known ones should have distinct properties. The goal is to have a precise and non-ambiguous ontology. --Horcrux92 (talk) 09:21, 26 January 2017 (UTC)

public key fingerprint

Under discussion
Description short sequence of bytes to identify a longer cryptographic public key public key fingerprint (Q6578920) String alphanumeric Tim Berners-Lee (Q80) → 4D4B 9D1D C032 0710 3CDC DE0B 344D 9666 1177 9EE7 Glenn Greenwald (Q5568842) → 734A 3680 A438 DD45 AF6F 5B99 A4A9 28C7 69CD 6E44
Motivation

The exact system (PGP, SSH, Groove etc) can be defined with a qualifier. ~ 17:36, 25 January 2017 (UTC)

Discussion
Having a property makes sense but there should be a notion that it always has to be sourced. ChristianKl (talk) 09:21, 27 January 2017 (UTC)
Support but wonder whether determination method (P459) should be a mandatory qualifier to describe how the fingerprint was generated. I also suggest creating a regular expression for "allowed values" which captures common syntaxes for public key fingerprints (covering PGP, X.509 certificates, etc). Dhx1 (talk) 14:28, 1 February 2017 (UTC)
@Dhx1: Thanks for the suggestion. I also thought of this but since I don't know how to create a regular expression, I'll leave that open to anyone who would like to do it. ~ 15:46, 1 February 2017 (UTC)
For OpenPGP the regexe should be: '([0-9A-F]{4} ){9}[0-9A-F]{4}' or more flexible but harder to read: '([0-9A-F]{4} ?){10}' -- MichaelSchoenitzer (talk) 19:30, 4 February 2017 (UTC)

Notified participants of WikiProject Informatics ChristianKl (talk) 17:58, 4 February 2017 (UTC)

•  Comment Isn't this fairly dynamic information? --Swpb (talk) 17:08, 15 February 2017 (UTC)
Comment @Swpb: Keys are generally changed very infrequently (2 years or more). Additionally, historical key information is just as important as current key information. Dhx1 (talk) 13:49, 19 February 2017 (UTC)

display size

Under discussion
Description diagonal lenght of the display in an electronic device. Display size (Q861066) Number display computer (Q68) number inch, centimeter Nexus 4 (Q49047) → 4.7 inches yes Q12538706
Motivation

I believe it is obvious why, where and how this property is needed and will be used Ogoorcs (talk) 01:54, 29 January 2017 (UTC)

Discussion
I see your point here, but I can't see why new properties proposals that can already be expressed trough a combination of "another property + qualifiers" couldn't have their specific equivalent property, particularly considering the benefits in user experience that simple properties provide (also against damages caused by newcomers trying to fill the gaps improvising properties failing to check it in similar entities).
I think that if your priority here is to preserve some kind of uniformity and to reduce complexity, opposing simple and catchy properties and so forcing users to think as machines really doesn't help this project; on the contrary, I think you should advocate for an equivalent to property meta-property: a way such that newcomers can shorcut an absurdely long "consist of: screen -> {determination method: diagonal measurement, lenght: value}" with "diagonal length: value" (equivalence classes for properties are needed for queries too: a simple query such as "dutch rappers" need a UNION operator for elements having properties "genre: rapping" and "instance of: rapper").
Anyway to me your argument is totally invalid, since you can apply it to proof that almost any property, for example birthplace, can be made useless having the right amount of information:
Julius Caesar -> birthplace -> Rome
is equivalent to
Julius Caesar -> partecipant of -> birth -> { of -> Aurelia Cotta
date: 100 BCE
place: Rome }
Ogoorcs (talk) 05:09, 12 February 2017 (UTC)

number of works

Under discussion
Description A qualifier on identifiers, for databases of e.g. works by creator or works by location, giving the number of works in the external database that have a relationship to the creator or location identified by this identifer. Number eg: for use in en:Template:Art UK bio, to display the number of paintings linked to that painter in the Art UK database qualifier on external identifier statements Simon Du Bois (Q12056662) : Art UK artist ID (P1367) → dubois-simon-16321708, qualifer: number of works → 9 the external website in question Currently I have been using quantity (P1114) for this relationship; the new property would replace these uses. change uses of quantity (P1114) as a qualifier on Art UK artist ID (P1367) to use this new property instead
Motivation

This property is for where we have an external identifier that is a key for some external database, to give the number of rows/items/objects in that database related to the identifier (eg for an external database of painters and paintings, the number of paintings in that database associated with this painter ID).

This information has previously been widely edited in by hand in uses of the template en:Template:Art UK bio: it gives the reader a better idea of how rich the external resource is likely be, and so how much the link may be worth clicking through to.

The number can also have maintenance uses: for example in the columns of tracking pages like en:Wikipedia:GLAM/Your_paintings/Painters_born_1850-1874, sorting by the "number of works" column allows Mix'n'match searching to be prioritised for the painters most heavily represented in the collection.

I have initially been putting this information onto Wikidata using quantity (P1114) as a qualifier on Art UK artist ID (P1367) identifiers, eg diff, but a number of users have complained that P1114 is too generic, and its intended meaning as a qualifier on an external identifier was not immediately clear; and that it would be therefore better to create a new property specifically for this role.

Better suggestions are very welcome for the property name, but ideally it should be quite short and concise. Jheald (talk) 15:25, 9 February 2017 (UTC)

Discussion
•  Support though I think the label should be clear this is "related items", not alternative versions of the same item. ArthurPSmith (talk) 17:29, 9 February 2017 (UTC)
• So perhaps "related match count" ? But that's still quite cryptic
Another alternative would be not to make this quite so generic, but focus it more narrowly for use on databases of works-by-painter or works-by-collection or works-by-location etc, and just call it "number of works". This might be a lot more transparent to readers meeting the property on an item for the first time. Jheald (talk) 11:03, 11 February 2017 (UTC)
• I would want that it's used with an additional qualifier that specifies the type of item that counted. Maybe we could also use unit=artwork? ChristianKl (talk) 13:20, 11 February 2017 (UTC)
• You can't put a qualifier on a qualifier, it's not possible. There may be several qualifiers attached to a statement -- we can't rely on the software preserving (or displaying) them in any particular order; especially if values get updated. Jheald (talk) 16:05, 11 February 2017 (UTC)
•  Support. --Swpb (talk) 16:49, 15 February 2017 (UTC)
•  Comment I have gone ahead and changed the proposed name to "number of works", and updated the description accordingly diff Jheald (talk) 20:50, 18 February 2017 (UTC)

CPUID code

Under discussion
Description CPUID identification code String "cpuid" in en:template:Infobox CPU hexadecimal string Intel Core i7-6700 (Q28739510) → 506E3 (see http://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=57560)
Motivation

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

Discussion
Comment - no formatter URL to link directly to these values? ArthurPSmith (talk) 16:46, 10 February 2017 (UTC)
•  Support. I took the liberty of adding the formatter URL. --Swpb (talk) 16:37, 15 February 2017 (UTC)
• @Swpb, Mikayé: That formatter URL does NOT work with the supplied example of 506E3 - it gives an invalid CPU ID error. ArthurPSmith (talk) 20:02, 16 February 2017 (UTC)
• The formatter is not good. The value should be the value returned by the cpuid instruction, not the id on cpu-world website. I gave the website as an example of source to obtain the value for a specific CPU. I think Swpb made a confusion between the two cpuid. Maybe the cpu-world id can be another property but that's another story... I removed the formatter. Mikayé (talk) 10:27, 17 February 2017 (UTC)
•  Support. This looks very useful to me. YULdigitalpreservation (talk) 14:50, 16 February 2017 (UTC)

objective of a project or mission

Under discussion
Description {{ | en = desired result or outcome | de = angestrebtes Ergebnis }} [[d:goal (Q4503831)|no label]] (goal (Q4503831)) Item projects, missions?, events, projects, games, life (kidding) device, discovery, process, change, discovery Manhattan Project (Q127050) → nuclear bomb (Q9177152) Adding the desired outcome to well-known projects, search for projects with a specific goal yes, if there are bots that can figure out the goal of a projects (f.e. from their Wikipedia page)
Motivation

better categorizing of project by goal, allows to search for failed attempts to do something or similar requests  – The preceding unsigned comment was added by SparkyC0la (talk • contribs) at 1 February 2017‎ (UTC).

Discussion
•  Support We have a number of properties expressing causal and temporal relationships (cause of (P1542), immediate cause of (P1536), contributing factor of (P1537), followed by (P156)), but none that I'm aware of expresses intent. --Swpb (talk) 16:32, 15 February 2017 (UTC)
•  Support I think I support this, however I'm struggling to think of another example that would work in this fashion, with an item as target value and not immediately obvious - Human genome project - human genome? Also perhaps the name should be shortened to just "objective"? ArthurPSmith (talk) 20:13, 16 February 2017 (UTC)
• "Objective" would be more generic, but runs the risk of ambiguity with the other meanings of the word, namely grammatical and optical. The indefinite article should be dropped though. Is it really a problem if the target item is obvious to a human? If a project and its aim have separate items, shouldn't they be explicitly linked, even if their names suggest the link to a human reader? --Swpb (talk) 13:44, 17 February 2017 (UTC)

category contains

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

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

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

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

Discussion
•  Support so I assume you would transition all the P360's on categories to this new property? I think it's fine to be more specific like this, so I support it. ArthurPSmith (talk) 18:30, 13 February 2017 (UTC)
•  Support per the thorough consideration given above. --Swpb (talk) 16:25, 15 February 2017 (UTC)
•  Support. Thank you for proposing this. I agree that this would make creating lists easier and more flexible. YULdigitalpreservation (talk) 14:52, 16 February 2017 (UTC)

naval unit

Under discussion
Description Naval unit no label (Q20749395 Hopp til: navigasjon, søk ) for egenskapen Naval unit) MISSING Skip N/A MISSING Classification of naval unit Task Force 11 and 9th Submarine flotilla
Motivation

(To show in wich units a naval vessel have fighted in.) --Pmt (talk) 21:09, 9 October 2016 (UTC)

Discussion
•  Wait This proposal needs more detail before it can be meaningfully assessed. Why can't more generic properties like part of (P361) or member of (P463) be used? --Swpb (talk) 16:15, 15 February 2017 (UTC)
• @Pmt: Can you fill in the missing information? ChristianKl (talk) 21:42, 19 February 2017 (UTC)

statement supported by

Under discussion
Description entity that supports a given statement Item Choekyi Gyaltsen, 10th Panchen Lama (Q83312) followed by (P156) Gyaincain Norbu (Q724350), People's Republic of China (Q148); Choekyi Gyaltsen, 10th Panchen Lama (Q83312) followed by (P156) Gedhun Choekyi Nyima (Q372526), Central Tibetan Administration (Q326343) Use of designated as terrorist by (P3461) can be replaced with instance of (P31) terrorist organization (Q17127659) with this qualifier statement disputed by (P1310)
Motivation

This property is a counterpart of statement disputed by (P1310). Even references are always supposed to support the claim, stated in (P248) can not state that the statement is who's position, so we need a qualifier for this. GZWDer (talk) 07:40, 13 February 2017 (UTC)

Discussion
•  Support ChristianKl (talk) 11:26, 14 February 2017 (UTC)
•  Support --Swpb (talk) 16:09, 15 February 2017 (UTC)
•  Support. This could be helpful for making explicit what the positions of different people/organizations/etc are. YULdigitalpreservation (talk) 14:54, 16 February 2017 (UTC)

object has role

Under discussion
Description role held by the object of a statement in the context of that statement role (Q4897819) Item statements (proposed property is a qualifier only) any w/ qualifier "object has role"=confessor (Q21500210) w/ qualifier "object has role"=upper bound (Q21067467) Migration of the myriad current uses of as (P794) and has role (P2868) for this purpose as (P794): A poorly defined property sometimes used for this purpose, which we are attempting to deprecate has role (P2868): Often used for this purpose, but more properly specifies a role of the subject item
Motivation

From this discussion about current use and misuse of as (P794), it has emerged that that property and has role (P2868) are often used to indicate a role for the object of a statement, rather than the subject, and that this distinction merits a separate property. I hereby propose that property, and propose that has role (P2868) be consequently restricted to statements about the subject item (which is its predominant use). @GZWDer, Jheald: --Swpb (talk) 15:37, 15 February 2017 (UTC)

Discussion

Support should we also merge type of kinship (P1039) and version type (P548) to this property?--GZWDer (talk) 15:40, 15 February 2017 (UTC)

Either that or make them sub-properties; between those two options, I don't have an opinion one way or the other at this point. --Swpb (talk) 15:46, 15 February 2017 (UTC)
I don't see a reason for merging. Subproperties work well enough. ChristianKl (talk) 18:35, 15 February 2017 (UTC)
It is inconsistent that relative (P1038) uses type of kinship (P1039) but superproperty significant person (P3342) uses as (P794) as qualifier.--GZWDer (talk) 18:59, 15 February 2017 (UTC)
I don't think that inconsistency is a problem. It's the nature of all sub-properties that they could be replaced by their parent. --Swpb (talk) 19:12, 15 February 2017 (UTC)
Using this property does not make new confusion. The reason of we having sub-properties is that they may be used in the same condition with different meaning, otherwise we can merge them to one property. location (P276) and part of (P361) is both already merged with (at least) 3 different properties.--GZWDer (talk) 19:29, 15 February 2017 (UTC)
Just a note: The major use of instance of (P31) as qualifier should also be merged to this property. I have started Property talk:P31#P31 as qualifier.--GZWDer (talk) 15:53, 15 February 2017 (UTC)
Agreed. --Swpb (talk) 15:57, 15 February 2017 (UTC)

Support I think this will help clear-up. Though I'm not sure that about that use of mass (P2067) with lightweight class (Q26211786) -- but it's the use of P2067 I'm not sure about, rather than this qualifier. Jheald (talk) 16:12, 15 February 2017 (UTC)

•  Support not sure if we can get a better name, but the general idea makes sense to me. Maybe we should post an addendum on the basic membership properties page about the role-related properties. ArthurPSmith (talk) 18:31, 15 February 2017 (UTC)
• We may add "specifically" as alias.--GZWDer (talk) 19:00, 15 February 2017 (UTC)

Support. This would make things more clear. But probably the subject item should be something more generic than role (Q214339) (social role) - maybe role (Q4897819). Valentina.Anitnelav (talk) 20:20, 16 February 2017 (UTC)

• Indeed. So changed. --Swpb (talk) 20:38, 16 February 2017 (UTC)

BioRxiv ID

Under discussion
Description identifier of a document in bioRxiv, a preprint repository for the biological sciences launched in November 2013 BioRxiv (Q19835482) External identifier biorxiv at en:Template:Cite journal scientific articles \d{6} TP53 copy number expansion is associated with the evolution of increased body size and an enhanced DNA damage response in elephants (Q28597702) → 028522 http://biorxiv.org/search/limit_from:2010-01-01%20limit_to:2017-02-16%20numresults:10%20sort:relevance-rank%20format_result:standard https://doi.org/10.1101/\$1 Import all 8420 articles to Wikidata arXiv ID (P818)
Motivation

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

Discussion

CiteSeerX ID

Under discussion
Description a string of digits and dots found in a CiteSeerX URL CiteSeer (Q2715061) External identifier citeseerx at en:Template:Cite journal scientific article \d+.\d+.\d+.\d+.\d+ The immune response in autism: a new frontier for autism research (Q22241718) → 10.1.1.329.777 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=\$1 Yes
Motivation

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

Discussion

NCJ ID

Under discussion
Description ID af an publication, report, article, or audiovisual product at National Criminal Justice Reference Service National Criminal Justice Reference Service (Q6972009) External identifier en:Template:NCJ publication, report, article, or audiovisual product \d{6} Measures of Gun Ownership Levels for Macro-Level Crime and Violence Research (Q28798208) → 203876 https://www.ncjrs.gov/App/Publications/abstract.aspx?ID=\$1 Yes
Motivation

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

Discussion

OSTI ID

Under discussion
Description ID of a scientific article at Office of Scientific and Technical Information Office of Scientific and Technical Information (Q2015776) External identifier osti at en:Template:Cite journal scientific article \d+ Cataracts induced by microwave and ionizing radiation (Q28798299) → 6071133 https://www.osti.gov/scitech/biblio/\$1
Motivation

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

Discussion

Cyworld ID

Under discussion
Description ID of the subject at Cyworld Cyworld (Q29760) External identifier en:Template:Cyworld, ko:틀:싸이월드 people, organization \d+ Kim Sa-rang (Q464663) → 27684413 http://cy.cyworld.com/home/\$1 From enwiki and kowiki
Motivation

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

Discussion

Star Wars Databank

Under discussion
Description ID of a fictional character at Star Wars Databank Star Wars Databank (Q3968343) External identifier en:Template:Star Wars Databank fictional character [a-z\-]+ Qui-Gon Jinn (Q51736) → qui-gon-jinn http://www.starwars.com/databank/\$1/ from Wikipedia
Motivation

see usage GZWDer (talk) 18:07, 18 February 2017 (UTC)

Discussion

type of reference

Under discussion
Description used to specify the type of a reference Item references Joris Ivens (Q238616) date of death (P570) 28 June 1989 reference URL (P854) http://resolver.kb.nl/resolve?urn=KBNRC01:000031052:mpeg21:a0087 → death notice (Q2438528)
Motivation

There was an existing property proposal for death notes which wasn't well received because it's too specialized. This property would allow references to be tagged as death notes and also as other types that might be of interest. ChristianKl (talk) 18:20, 18 February 2017 (UTC)

Discussion
•  Support Interesting approach, this might be helpful also for other type of references to categorise them and to query them. --Hannolans (talk) 22:37, 18 February 2017 (UTC)
•  Question do you mean "type of record" or "record type", grammatically I am unsure about the suggestion, especially as it is the record that you are identifying, not the reference. Also, if we start to use these types, in references, how will it start to change the dynamics of internal use of a "type" as an item or in identifying an item, to now referring to an external reference with the same item. Has the system (and its usage tools) got enough smarts to be able to differentiate?  — billinghurst sDrewth 03:47, 19 February 2017 (UTC)
• I wouldn't add it as a qualifier to the item but in the reference with the same semantics that retrieved (P813) currently uses. I'm open to renaming it into "type of record" if that's clearer. ChristianKl (talk) 22:01, 19 February 2017 (UTC)