Wikidata

Wikidata:Property proposal/Archive/45

< Wikidata:Property proposal‎ | Archive

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Please restrict each archive page to at most 80 proposals, to avoid the Lua error: too many expensive function calls issue that messes up previous archive pages.


production designer

Descriptionperson responsible for the overall look of a filmed event
Representsproduction designer (Q2962070)
Data typeItem
Template parameter
Domainfilm (Q11424), television program (Q15416)
Allowed valueshuman (Q5)
ExampleGone with the Wind (Q2875) → William Cameron Menzies (Q261997)
Mad Max: Fury Road (Q1757288) → Colin Gibson (Q22075468)
Robot and gadget jobsimport from infoboxes
Motivation

See also the discussion for costume designer (P2515). Production designers are one of the main billed cast with specific awards for their work at major film awards. They are featured in the infoboxes in several Wikipedias. Máté (talk) 10:15, 18 January 2016 (UTC)

Discussion
  •   Support - Mbch331 (talk) 14:07, 18 January 2016 (UTC)


YouTube user name

   Not done
DescriptionUser name of a person, or organisation, on YouTube
Data typeString
Domainhuman (Q5), organization (Q43229)
ExampleAvril Lavigne (Q30449) => avrillavigne
SourceYouTube
Formatter URLhttps://www.youtube.com/user/$1
Motivation

Proposing with the aim of splitting website account on (P553) (see Wikidata:Project chat#Website_user_names). Per this, YouTube is the third-most used value for P553, after Twitter & Facebook. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:12, 22 July 2015 (UTC)

Discussion
  •   Comment The problem with Youtube is that some users have names like "https://www.youtube.com/<name>" others "https://www.youtube.com/user/<name>" or "https://www.youtube.com/channel/<name>". It's even possible that two of these exist and are unrelated, leading to different content. To avoid such ambiguity, URL-datatype seems more appropriate. --- Jura 18:43, 22 July 2015 (UTC)
  •   current proposal with string datatype. --- Jura 18:47, 22 July 2015 (UTC)
  • https://www.youtube.com/mbch331 and https://www.youtube.com/user/mbch331 both point to my YouTube channel. (Wouldn't know the channel id as I never use it) Mbch331 (talk) 11:41, 23 July 2015 (UTC)
  • Try https://www.youtube.com/DonaldTrump which is for Donald Trump.
    Hillary Clinton is at https://www.youtube.com/channel/UCLRYsOHrkk5qcIhtq033bLQ (not at https://www.youtube.com/user/channel/UCLRYsOHrkk5qcIhtq033bLQ ). --- Jura 13:02, 23 July 2015 (UTC)
    • It's not clear that either of those is for the person, rather then the campaign. YouTube does not appear to use a /user/channel/ format. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:12, 23 July 2015 (UTC)
      • Your comment doesn't actually address the issue of custom URLs, such as "youtube.com/DonaldTrump". Merely focusing on legacy usernames (that are being phased out) doesn't seem forward orientated. For an overview, see "Understand your channel URLs". --- Jura 04:27, 24 July 2015 (UTC)
        • It most certainly does address that. And the page you cite says that, while user names are no longer issued, existing names (and the URLs of which they are part) are still valid and may still be used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 27 July 2015 (UTC)
  • I think the datatype here should be URL. And restraints are either it has https://youtube.com/user/<username>, which is the same as https://youtube.com/<username> or it has https://youtube.com/channel/<channelid>, where the channel id is 24 chars long (latin alphabet) and has to start which UC. User id isn't case sensative, channel id is. Mbch331 (talk) 13:16, 23 July 2015 (UTC)
    • That wouldn't work for the Donald Trump sample, try https://www.youtube.com/user/DonaldTrump --- Jura 13:19, 23 July 2015 (UTC)
      • You're right. Never noticed that this was the case. In that case all type should be unique, but youtube.com/user/$1 doesn't have to be unique when comparing to youtube.com/$1. Mbch331 (talk) 13:24, 23 July 2015 (UTC)
    • No. This property should be for YouTube user names, type=string, for the same reasons that we don't store full URLs for other identifiers. Other properties may be created for YouTube channels, if needed. We shouldn't muddle two types of identifier in this way. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:12, 23 July 2015 (UTC)
      • What's your plan for Donald Trump? --- Jura 15:32, 23 July 2015 (UTC)
  •   Support I looked at YouTube's API and they distinguish user names from channel IDs. I also found [1], it seems the Donald Trump example above is a custom URL, not a user name or channel ID. I don't think storing the entire URL would be a very structured way of storing the data. - Nikki (talk) 17:48, 23 July 2015 (UTC)
    • The link you provided is most helpful, but it seems they are dropping the "legacy username" from the API. --- Jura 19:26, 23 July 2015 (UTC)
    • @Nikki: Youtube removed what they call the "legacy username" from their api and exclude the creation of new ones. For new users, only "custom URI" become available and we need to include these in one way or the other. The proposal below for a single URI based property seems better structured (it's called uniform identifier for a reason) and consistent with other properties for complex naming schemes. --- Jura 08:58, 1 August 2015 (UTC)
      • As you missed it above, I'll repeat: YouTube says that, while user names are no longer issued, existing names (and the URLs of which they are part) are still valid and may still be used. If you wish to start an RfC to change our policy on identifiers to always store full URIs rather than the UID component, please do so in an appropriate forum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 1 August 2015 (UTC)
        • Can you provide us with a link to what you describe as policy? --- Jura 10:45, 1 August 2015 (UTC)
      • YouTube's API still supports the username using the "forUsername" parameter (see [2] and [3]). I don't think that storing a single URL property is better structured. It would combine multiple incompatible things into a single property (channel ID and username require different API queries, custom URL doesn't seem to be usable in the API at all). There are also many possible URLs for the same ID or name (http vs https, www vs no www, desktop vs mobile, trailing slash vs no trailing slash, etc) which is not a sign of well structured data. - Nikki (talk) 17:42, 1 August 2015 (UTC)
        • You are right about the "forUserName" api parameter. It seems that v3 limited the use of legacy usernames, but still allows this. CustomURLs probably need to use the query in the api. [4]. If one relies on the api, one should be prepared to process URLs
          The main use for any of these access methods is to actually go to a channel. This works well with URLs and one of the issues we had with the current solution is that this isn't always possible. As any string, we can easily normalize URLs. Even for such simple things as Twitter account names, you already had to do quite a lot of normalization. If actual URLs are used, this is easier, as the input is already limited and we can define the correct format beforehand. --- Jura 06:05, 2 August 2015 (UTC)
  •   Oppose This proposal follows the approach of Twitter username (P2002), Instagram username (P2003) etc. However, youtube has different url formats (https://www.youtube.com/<name> and https://www.youtube.com/user/<name> so unfortunately in this case the approach fails. --Pasleim (talk) 19:51, 4 October 2015 (UTC)
  •   Comment As pointed out below, https://www.youtube.com/DonaldTrump represents a channel not a user and is equivalent to https://www.youtube.com/channel/UCAql2DyGU2un1Ei2nMYsqOA - the objections are therefore moot, and this property should now be created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:01, 7 January 2016 (UTC)
  •   Oppose Having worked with the YouTube API v3 this proposal makes little sense. YouTube has legacy YouTube users and Google+ (is it Google Account now?) users and the new API uses channels that aren't tied to a single username. The short vanity URL (proposal early version) can be reassigned -- [5]. Also, I'd like to see a good use case besides social-media-for-marketing or it "helps Google make more money". Dispenser (talk) 05:22, 26 February 2016 (UTC)
    •   Comment I'll speak to use cases from a researcher's perspective. Social media use is a critical part of human–computer interaction (Q207434) studies: see 'CSCW social media' in Google Scholar for examples. Social media properties in Wikidata afford observation and comparison of social media use across classes of entities. For instance, a basic study would be mining tweets separated by gender of person. Another could be video style of musical artists across genres. Since many companies have APIs that allow discovery of follower relationships, social media properties in Wikidata also afford building a derived social graph. This is only possible when social media is part of the linked data graph. Runner1928 (talk) 19:39, 26 February 2016 (UTC)
      • That's a bit of a tautology and gender is available via Google+. What I was really trying to ask is "What data could Wikidata harvest from this property?" Seeing how these social websites rise and fall, it might be better to have a generic "External profile URL" for the social media stuff. Dispenser (talk) 22:10, 27 February 2016 (UTC)

  Not done Consensus not reached.--Micru (talk) 13:29, 27 February 2016 (UTC)


YouTube address

   Not done
DescriptionChannel address/User name/address of a person, or organisation's YouTube feed [6]
Data typeURL
Domainhuman (Q5), organization (Q43229)
Allowed valuesURLs starting with https://youtube.com/
ExampleAvril Lavigne (Q30449) => https://www.youtube.com/user/avrillavigne
Hillary Clinton (Q6294) => https://www.youtube.com/channel/UCLRYsOHrkk5qcIhtq033bLQ
Donald Trump (Q22686) => https://www.youtube.com/DonaldTrump (not https://www.youtube.com/user/DonaldTrump)
  •   Comment: This to replace the current use of website account on (P553) for Youtube. YouTube are basically channels, but these can be addressed as Youtube.com/<name> or Youtube.com/user/<name> or as Youtube.com/channel/<channel id>. Similar to other sites with complex addressing, we apply a single URL as identifier. This ensures that users aren't lost with too many concurring properties. --- Jura 17:06, 23 July 2015 (UTC)

  Not done Consensus not reached.--Micru (talk) 13:31, 27 February 2016 (UTC)

Baike.com entry

   Not done
DescriptionEntry in Baike.com (Hudong) encyclopedia
Representsbaike.com (Q1203487)
Data typeString
Domainall
Allowed valuesChinese text
ExampleJiang Zemin (Q16597) → 江泽民
Format and edit filter validationcheck that it's a real account
Formatter URLhttp://www.baike.com/wiki/$1
Motivation

Entry in leading Chinese encyclopedia Baike.com (known as Hudong).--Kopiersperre (talk) 21:59, 12 August 2015 (UTC)

Discussion
  Support. Joe Filceolaire (talk) 13:26, 24 August 2015 (UTC)
With 1 support without arguments and 2 opposes with the same argument that there is an alternative and nobody adressed the objections, this is   Not done. Mbch331 (talk) 14:34, 30 December 2015 (UTC)
@Mbch331: I think you have misread this. Three is only one oppose. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 30 December 2015 (UTC)
I looked like the second line was also a oppose, but it's part of Filceolaire's response. Then there is no clear consensus against or in favor and I've removed the not done. Mbch331 (talk) 15:07, 30 December 2015 (UTC)
  •   Oppose These are not authority control values, as far as I can tell they are wiki page titles subject to change. Josh Baumgartner (talk) 19:03, 5 January 2016 (UTC)
  •   Oppose No identifier. Snipre (talk) 17:12, 19 January 2016 (UTC)
    • We already have multiple existing properties like this (see above) and Lydia said very recently on the Wikidata mailing list (here) that links to other wikis are handled via statements. That implies to me that this proposal is valid as it is and should only be judged on whether or not the property would be useful. - Nikki (talk) 00:22, 14 February 2016 (UTC)
  •   Support I had a look and found references or external links to this site on (at least) 10 different Wikipedias, albeit not huge numbers of links. This does however seem like something which could be useful. - Nikki (talk) 00:22, 14 February 2016 (UTC)
  • There is also a Baidu Baike proposal, which was buried in the archive.--Kopiersperre (talk) 10:23, 14 February 2016 (UTC)

  Not done Consensus not reached.--Micru (talk) 13:33, 27 February 2016 (UTC)

standard unit

   Not done
DescriptionStandard unit for the quantity measured by this unit
Data typeItem
Domainunit of measurement
Allowed valuesunit of measurement (Q47574)
Examplemillimetre (Q174789) → metre (Q11573)
Motivation

In order to be able to process or query quantities with units, it may be necessary to bring them to the single unit. I.e. some distances can be expressed in kilometre (Q828224), some in mile (Q253276), weights in kilogram (Q11570), some in ton (Q11247037), some in pound (Q100995), which are not directly comparable but can be converted to common measure. It would be nice if for automatic processing we could specify that all metric length units should be converted to, say, metre (Q11573) - then every unit with standard unit marked as metre (Q11573) would be automatically recognized by tools as belonging to the same family and automatic processing of such quantities would be much easier.  – The preceding unsigned comment was added by Laboramus (talk • contribs).

Discussion
  •   Comment see #conversion_to_standard_unit above. --- Jura 15:41, 10 September 2015 (UTC)
    • Yes, similar, but not the same. You It would be more complex to ensure all length properties have the same standard unit without having dedicated property - i.e. if somebody says that yard is 36 inches, it may be non-trivial to figure out whether inch can be converted to meters. Having this knowledge explicitly would allow to scan for it and have bots or people enforce proper conversions more easily. That said, I support #conversion_to_standard_unit and if the majority things two properties are redundant, we can do with just one. --Laboramus (talk) 22:51, 10 September 2015 (UTC)
      • We should not be calculating conversions and storing the results of those calculations in Wikidata, as that would be original research. We should only be listing conversions when they are cited in source material, and as such what we list should be exactly as listed in the cited work. Josh Baumgartner (talk) 21:00, 5 January 2016 (UTC)
  •   Oppose. I expect the "number with units" datatype to deliver this automatically - i.e. all lengths should be stored internally in meters, no matter if the value is in inches or Angstrom, so all are comparable. If they fail to deliver then we can look at this again. Joe Filceolaire (talk) 15:06, 12 September 2015 (UTC)
That’s not how it works. A number with units is just a Quantity (value, minimum, maximum) and any item as unit – doesn’t have to be a number. —Galaktos (talk) 16:15, 12 September 2015 (UTC)
  •   Comment I think this might be covered by the above proposal #conversion to standard unit – if a statement tells us that one millimetre (Q174789) equals 0.001 metre (Q11573), we can assume that metre (Q11573) is the standard unit for millimetre (Q174789). —Galaktos (talk) 11:04, 13 September 2015 (UTC)
  • Thinking about this more. I don't think this property is useful for telling us that millimetres are measured in metres - that can be done with the conversion to standard units property proposed above as Galaktos said. This property could be useful for noting that mass is measured in kilogram and luminous flux is measured in lumen and I would   Support this proposal if it were ammended in this way. @laboramus:? Joe Filceolaire (talk) 12:27, 18 September 2015 (UTC)
  • Good idea.   Support with description changed to “standard unit for this quantity”. —Galaktos (talk) 19:43, 19 September 2015 (UTC)
I think it's a bit different proposal but equivalent to what I proposed, only applied to measured quantities instead of units. Maybe we need a separate proposal for that... --Laboramus (talk) 08:11, 12 October 2015 (UTC)
  •   Support "base unit" might be the term to use. --- Jura 13:28, 24 September 2015 (UTC)
  • "Base unit" has a specific meaning in the International System of Units; derived units are expressed in terms of base units, and some derived units have special names. For example, force is expressed in kg²⋅m / s² and one may use the special name newton for this derived unit, if one wishes. It would be confusing to assign a different meaning of "base unit" in Wikidata. Jc3s5h (talk) 20:43, 24 September 2015 (UTC)
    • I think you mean "SI base unit". --- Jura 15:44, 27 September 2015 (UTC)
  • If, for example, we wanted to have a unit to which every power measurement should be converted, we might choose the watt. But the watt is not an SI base unit, it is a SI derived unit with a special name. Jc3s5h (talk) 17:42, 23 November 2015 (UTC)
  •   Oppose We should not be deciding what unit is 'standard' for a measurement (such as 'mass is measured in grams'). I would be fine with an 'SI base unit' but it would only be those defined as such in SI and thus only apply to SI units and have no inherent relation to other measurement systems (ex: 'milligram' > 'gram'). We also should not be doing any conversions, all we should record on Wikidata are measurements and conversions recorded in cited sources. Josh Baumgartner (talk) 21:00, 5 January 2016 (UTC)
  •   Oppose A table on the Wikipedia side can do the job without all that stuff. To get feet from millimeter I don't need to first convert into meter and then into feet, I can directly convert using a table. Snipre (talk) 17:14, 19 January 2016 (UTC)
    @Snipre: This is not the point, this is a way to store the coefficient you would use in that "table" (btw. it's a calculation, not a table). author  TomT0m / talk pageé
    ;TomT0m I think this is the point: I can create a table with relation X mm = X*0.00328 feet and X m = X*3.28 and no X mm = X*3.28*Y feet where Y is your coefficient 0.001 for mm and 1 for m. My table will be bigger but I don't need to recover several parameter like the coefficient or the relation between mm and m. Snipre (talk) 17:00, 21 January 2016 (UTC)
    @Snipre: You can always harcode as many conversion you want in your code, with or without this. However if you encounter a unit you are not aware of, you won't be able to do nothing without couching your code. With that information in Wikidata, we can build more generic code which will be able to convert to "meters", for example, any length unit that can be expressed in meters, back and forth. author  TomT0m / talk page 17:17, 21 January 2016 (UTC)

  Not done Consensus not reached.--Micru (talk) 13:34, 27 February 2016 (UTC)

toll

   Done: fee (P2555) (Talk and documentation)
Descriptionfee or toll payable to use the subject
Representsfee (Q11765)
Data typeNumber (not available yet)
Template parameter"toll" in en:Template:Infobox bridge
Domainbridges, tunnels, roads
Allowed valuespositive numbers with units of currency. Should have a qualifier of start time (P580) or point in time (P585)
ExampleSecond Severn Crossing (Q1287969) 6.5 pound sterling (Q25224) (qualifier: start time (P580) 1 January 2015)
Sourceexternal reference, Wikipedia list article, etc.
Robot and gadget jobsimport from infoboxes
Motivation

This is a key property of toll bridges, tunnels, toll roads, etc. these change over time so this should be accompanied by a qualifier noting when it applies/ed. However this would be difficult to make mandatory as it is missing from e.g. en:Peace Bridge (Peace Bridge (Q1188691)). Thryduulf (talk: local | en.wp | en.wikt) 03:14, 12 November 2015 (UTC)

Discussion
  •   Support --Kopiersperre (talk) 08:18, 13 November 2015 (UTC)
  •   Comment Is this always going to be as simple as the given example? Surely, tolls can be more complex than this? Such as different prices for different types of vehicle, time of day, day of week, etc. Danrok (talk) 22:47, 23 November 2015 (UTC)
  •   Support - yes. I've previously thought about how this should be modelled when driving across the Sydney Harbour Bridge :-) I know that it has been tolled for its entire existence, but the amount has changed over time in some quite complex ways to model - not just increases in price. A few decades ago it stopped being tolled in the Northbound direction, but remained tolled southbound. A couple of years ago, the also introduced variable-pricing depending on the time of day (peak hour costs more, midnight costs less). I'm sure that these kinds of things have already been worked out by the OpenStreetMap community, can we connect our metadata to that for these kinds of geographic metadata terms. Wittylama (talk) 12:53, 1 December 2015 (UTC)
  •   Support as 'fee' being a 'payment required for use of an item or service'. There is no reason to restrict scope to transportation. Fees, tolls, fares, and other structures of payment can all be contained within this one property. Josh Baumgartner (talk) 19:04, 6 January 2016 (UTC)

  Done @Thryduulf, Kopiersperre, Danrok, Wittylama, Pigsonthewing, Joshbaumgartner:--Micru (talk) 16:18, 27 February 2016 (UTC)


fare

   Not done
Descriptionfare or fee payable to use the subject
Representsfare (Q1142227)
Data typeNumber (not available yet)
Template parameter?
Domainpublic transport (Q178512) (trains, buses, funicular railways, etc.)
Allowed valuespositive numbers with units of currency. Should have a qualifier of start time (P580) or point in time (P585)
ExampleBridgnorth Cliff Railway (Q4966907) 1.2 pound sterling (Q25224) (qualifier: point in time (P585) July 2015)
SourceWikimedia articles, external websites
Motivation

This is similar to "toll" proposed above, and might be combinable with it, but the concepts are slightly different. This is not intended to be used for all possible fares, but is useful for things with a small number of flat fares. Thryduulf (talk: local | en.wp | en.wikt) 03:14, 12 November 2015 (UTC)

Discussion
  •   Support --Kopiersperre (talk) 08:20, 13 November 2015 (UTC)
  •   Oppose Data of low interest and with high variability especially when considering the possible price reductions according to different criteria (age,...). Snipre (talk) 09:59, 26 November 2015 (UTC)
  •   Oppose Fee, fare, and toll are all payment descriptions that may represent different concepts within particular situations, but overall are more or less interchangeable. In any case, the differences are not significant enough to require a separate property. Thus I support a single 'fee' property that covers it all (see 'toll' proposal above). Josh Baumgartner (talk) 19:07, 6 January 2016 (UTC)

  Not done--Micru (talk) 16:20, 27 February 2016 (UTC)


defining characteristic

   Not done
Descriptiondefining attribute, trait (or similar) which all instances of this class-type item will have. See [7].
Data typeItem
Domainany class item (subclass of (P279))
Allowed valuesbroad scope
Example
Format and edit filter validation(sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17)
SourceOften just common knowledge, and normally mentioned in Wikipedia articles
Robot and gadget jobsProbably not for bots
Motivation

Fairly simple and obvious concept which I don't think is covered already. Should only be used in situations which cannot be claimed by using subclass of (P279) or instance of (P31). Danrok (talk) 01:08, 26 November 2015 (UTC)

Discussion
  •   Comment @Danrok: Is not this the same that has quality (P1552)   ? author  TomT0m / talk page 10:01, 26 November 2015 (UTC)
  •   Comment @TomT0m: Thanks, I had not seen that property. However, when I look at how it is being used, its not quite the same. Take for example fictional character (Q95074), and given name (Q202444). That's not really a defining attribute. A fictional character with no-name would still be a fictional character. What I had in mind was the basic and obvious attribute, which is absolutely mandatory in order for an item to belong to that class. Such as a venomous snake is venomous, otherwise it is not a venomous snake. Danrok (talk) 13:08, 26 November 2015 (UTC)
  • This seems too domain-specific. What is interesting to one domain ("list of tallest buildings" -> architecture) may be less interesting to another domain ("buildings pioneering the use of x-type construction"). "has quality" seems sufficient on the point. --Izno (talk) 17:58, 28 December 2015 (UTC)
  •   Weak support. I saw that freshwater marsh (Q31455) is instance of (P31) marsh (Q30198), but its defining characteristic is that it's fresh water (Q102192). Should I use has part (P527)? That seems like I'm only listing one part of many, which isn't right. made from material (P186) sort of infers that something is human-made. But "defining characteristic" seems just right. Runner1928 (talk) 22:05, 6 January 2016 (UTC)
  •   Oppose. Use has quality (P1552), with preferred rank if it's really necessary. has quality (P1552) can express perfectly well that height is a sine qua non of skyscrapers; the proposed property doesn't really add anything. Swpb (talk) 20:48, 7 January 2016 (UTC)

  Not done Redundant.--Micru (talk) 13:40, 27 February 2016 (UTC)


autores.uy database id

   Done: autores.uy ID (P2558) (Talk and documentation)
DescriptionA unique identifier of uruguayan authors and artistic, scientific or literary works.
Data typeString
DomainAuthors of artistic, scientific or literary works of Uruguayan nationality.
Allowed values[0-9]{5}
ExampleMario Benedetti (Q16285) → 485
Sourcehttp://autores.uy/
Formatter URLhttp://autores.uy/autor/$1
Robot and gadget jobsbots can help adding entries
Motivation

Autores.uy is a website maintained by Creative Commons Uruguay and supported by National Library of Uruguay, National Museum of Visual Arts and Ministery of Education and Culture (Uruguay); and its goal is Zerabat (talk) 15:11, 24 December 2015 (UTC)

Discussion
  • "and its goal is..?" Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 24 December 2015 (UTC)
    •   Support autores.uy's goal is to systematize information about Uruguayan authors and intellectual works. It has stable links and it is based on reliable bibliographical sources.--Pepe piton (talk) 17:15, 18 February 2016 (UTC)
  •   Question Are these numbers stable? I just clicked on the '485' link and got Mario Benedetti's page, whereas I found Eduardo Galeano's number now is '3'. I'm concerned that these 'node' numbers may not be stable over time, and may not reflect any real authority control number, but just be a function of the site's content management system. Josh Baumgartner (talk) 20:25, 6 January 2016 (UTC)
    • Mabye you are right, and these numbers could not be stable. --Zerabat (talk) 15:46, 27 January 2016 (UTC)<
      •   Support The site has migrated to a stable URL format (i replaced the stable format in the 'Property documentation').--Zeroth (talk) 16:38, 18 February 2016 (UTC)

  Done @Zerabat, Joshbaumgartner, Pepe piton, Zeroth:--Micru (talk) 17:09, 27 February 2016 (UTC)

First item in sequence

   Not done
DescriptionFirst item of this sequence, e.g. pilot or first episode of a television series, inaugural officeholder if clearly identifiable. Alternate ways to retrieve the initial item could be, if defined, through the qualifier "follows=novalue", a date property, or some of the values used in the qualifier "series ordinal".
Data typeItem
Template parameter"first"/"inaugural" in w:Template:Infobox_official_post
Domainitems for series, offices, etc.
Allowed valuesitems with a property linking to that series/position
Examplew:President of the European Commission → w:Walter Hallstein (note the infobox on the linked page)
Sourceinfoboxes
Robot and gadget jobsHarvest Templates (Q21914398)
Proposed byJura 14:03, 7 January 2016 (UTC)
Discussion

  Not done Consensus not reached.--Micru (talk) 13:48, 27 February 2016 (UTC)


DEFAULTSORT

   Not done
Description
Proposition at languages level
At the end of definitions of the properties there are tables of links from Wikidata to other wikis.
We can add to each of these links a DEFAULTSORT field, with a priority mechanism described below, which is valid only for this couple of wiki + language.
If a lastname and 0 or 1 firstname is defined, the DEFAULTSORT 1 is "lastname then firstname". For other elements than Person this sort is the consensual one.
If a check box "firstname then lastname" or "reverse order", DEFAULTSORT 2 is the "reverse order" and overrides DEFAULTSORT 1. For other elements than Person this sort would be a switching between two simple options.
If a user has defined the DEFAULTSORT 3 is the text "value provided by the user" and overrides DEFAULTSORT 2.
The eventual future regional-sort can not use this option DEFAULTSORT 3 to not disturb the sorting in the main language.
Details in the Wikidata side, as source of DEFAULTSORT
For each packet (element + language + wiki), there is a group of options DEFAULTSORT 1 to 3.
An interface to get the DEFAULTSORT options of a category is available in all wikis for templates and in Wikibase Client/Lua.
Perhaps another interface to remotely define the DEFAULTSORT options of each packet (element + language + wiki) must be in the Mediawiki configuration of each wiki and could be in Wikibase Client/Lua.
Wikidata could also use the DEFAULTSORT property as client to sort its own categories or a part of them.
Details in the wiki side, as client of Wikidata
Each wiki can activate or not its client of DEFAULTSORT property, and activate or not the DEFAULTSORT property in each category.
In each category where DEFAULTSORT property is active, but bad defined, an error is displaid and one other alerts local admins.
Each wiki must chose a default packet (element + language + wiki).
Each category can change all or only some part in the wiki paquet definition.
Each user can chooses its own language to sort all categories of a wiki.
The priority level for the sort language is the item, else the user one, else the category one, else the wiki one.
If the priority change is partial, it can change other part of the paquet definition.
Data typeString
Template parameternone, for categories only
DomainPerson or any sortable items of the string type
Allowed values{ "normal", "reverse", "result", "regional" } + result + ( regional-sort-code in eventual future )
Example{{DEFAULTSORT|normal}} → {{DEFAULTSORT|reverse}} → {{DEFAULTSORT|result|De Magon, Ricardo}} → {DEFAULTSORT|regional|cyrillic-en|Ovechkin, Alexander}}
Format and edit filter validation1 to 3 strings following allowed values and options DEFAULTSORT 1 to 3
Robot and gadget jobsA bot to prepare the activation of new client wikis, collecting sort orders in many categories, before activation, could help to automatize the DEFAULTSORT definitions of packets (element + language + wiki).

This proposition answers to previous limits:

  • we get a new sorting property that works
  • specify the sortkey to be used for each language/script combination
  • sv.Wikisource and sv.Wikipedia do not use the same alphabet
  • easier to select the correct sortkey than monolingual string-datatype
  • The defautsort key is language-dependent
  • It should be handled with labels, not as a [simple] property.

--Rical (talk) 21:50, 13 January 2016 (UTC)

Motivation
  • Base of Wikidata: do once in Wikidata a shared task or service.
  • Propose an implementation to answer to a several times sought property.
  • Automatize the collection of existing sorting options paquet from many wikis.
  • To correct errors, detect sorting differences for one item, in 1 category when other(s) are equals, with the same options paquet.
  • Centralize the knowing and the know how to enhanse them.
  • Build an enough fiable robot able to propose a DEFAULTSORT and a right method in many new cases.
  • Offer a sorting service for any mediawiki wiki, in or out of WMF.
Along and across the automatic collection
  • Detect the differences in the value of SORTKEY, and the difference in the method to get the SORTKEY, the minimal options paquet to do the same.
  • To correct errors, see behind.
  • When detecting differences, search regularities inside exceptions in differences of method.
  • Build an enough fiable robot able to propose a DEFAULTSORT and a right method in many new cases.
  • Try and evaluate this robot after enough categories importation, when importing sort options from other categories.
Types of categories to compare
  • differences of projects: Wikipedia / Wikisource ...
Example: Swedish sv.Wikisource and sv.Wikipedia do not use the same alphabet.
  • differences of subjects: Biologists / Authors / Sculptors / Streets names / Genealogic research out of WMF ...
  • differences of countries: British / USA, Australia / USA, Canada / France, Maroco / France...
Example: France use "Van Gogh", Canada uses "Gogh, Vincent". See in VIAF.
  • differences of languages: foreing languages adapted in local language, like: cyrillic / cyrillic-en (cyrillic names modified in english).
Example: The transcription of the Cyrillic alphabet varies from one language to another.
Александр Овечкин, give «Ovetchkine, Aleksandr» in frwiki and «Ovechkin, Alexander» in enwiki.

--Rical (talk) 21:50, 13 January 2016 (UTC)

Discussion

  Comment The same property P1964 (P1964) was created and deleted last september (Wikidata:Requests for deletions/Archive/2015/Properties/1). Cdlt, VIGNERON (talk) 09:39, 11 January 2016 (UTC)

Previous discussion on 2016-01-09: propriété DEFAULTSORT property --Rical (talk) 22:56, 11 January 2016 (UTC)
  Oppose per previous discussion --Pasleim (talk) 15:51, 22 February 2016 (UTC)
  Comment To work well with categories at Wikipedia, this would probably need some sort of support from the MediaWiki software. Maybe a new datatype?
--- Jura 13:40, 27 February 2016 (UTC)

  Not done Lack of support.--Micru (talk) 13:49, 27 February 2016 (UTC)

GPU

   Done: GPU (P2560) (Talk and documentation)
Descriptiongraphics processing unit within system
Representsgraphics processing unit (Q183484)
Data typeItem
Template parameterWikipedia infobox parameters, if any; ex: "population" in en:template:infobox settlement
Domainelectronic devices eg computers, phones, gaming consoles etc
ExampleXbox 360 (Q48263) → ATI Xenos (Q1192582)
Motivation

We already have CPU (P880), why not GPU? Would be useful for electronic devices. Datatype could also be string if preferred. -- numbermaniac (talk) 02:21, 12 January 2016 (UTC)

Discussion
  • CPU I can say is necessary for e.g. en:template:infobox video game. I wonder if the CPU property can't be qualified to indicate that the device in question is a GPU (or whether such an idea makes sense--I haven't reviewed whether GPUs are special kinds of CPUs, though they certainly originated as such). --Izno (talk) 17:31, 19 January 2016 (UTC)
  •   Support, but extend to the video hardware system. It also maybe hard to separate duties on highly integrated systems like the Amiga. Dispenser (talk) 04:43, 26 February 2016 (UTC)

  Done @Numbermaniac, Izno, Dispenser:


plural form

   Not done
Descriptionplural form of label
Data typeMonolingual text
Domainterms
Examplesecond (Q11574) → seconds, hour (Q25235) → hours
Motivation

Adapted from Wikidata:Property_proposal/Archive/44#P2521 (female form of label (P2521)).

This property may be useful for units of measure. Currently an user see this: speed of light (Q2111) numeric value (P1181) 299 792 458 meter per second. In future the WikiBase repo software can use this property for the classic form {{PLURAL:$1|}} (or other similar), and a user can see speed of light (Q2111) numeric value (P1181) 299 792 458 meters per second. β16 - (talk) 09:53, 26 January 2016 (UTC)

Discussion
  •   Support per requester. The "non-singular value with singular unit" problem isn't urgent, but it is a problem. Swpb (talk) 17:51, 26 January 2016 (UTC)
  •   Comment some languages don't use the plural when there is a number already indicating the quantity (Hungarian) while other languages may use different plurals depending on the number preceding the noun (Russian). So, what I'm saying is, proceed with caution :). – Máté (talk) 18:04, 27 January 2016 (UTC)
  •   Oppose. First of all, this is linguistic data, which is Wiktionary's domain. Second, this would result in a full extra statement for every language for every item. (Several billion statements.) We have "label" as a separate type of data for a reason. Third, regarding the example you gave, we already have P558 (P558), which is probably preferable to having the full text anyway. --Yair rand (talk) 22:46, 31 January 2016 (UTC)
    •   Comment The question isn't if this is someone's reserved turff or not, but can this be provided to users in a structured form or not? If it's a list in PDF format, it would be with Commons and possibly transcribed at Wikisource, but that couldn't be made use of here or elsewhere for specific items either. Wikidata is the provider for structured data.
      --- Jura 07:23, 2 February 2016 (UTC)
  •   Oppose In my opinion, building a linguistic database if out of scope of Wikidata. While having structured linguistic data is a useful project in its own, it is something that would have to be part of Wiktionary. --Srittau (talk) 13:39, 3 February 2016 (UTC)
    • There is actually a plan to do just that at Wikidata, as Wiktionary has some technological issues.
      --- Jura 06:28, 8 February 2016 (UTC)
      @Jura1: Do you have any links to the discussion about that "plan"? Clearly it's not a very well-known plan, since you're the only one of 6 people who even mentioned it, and this proposal was not made as part of any plan. Intgr (talk) 13:01, 8 February 2016 (UTC)
      There are multiple proposals to integrate Wiktionary into Wikidata. The most recent proposal is Wikidata:Wiktionary/Development/Proposals/2015-05. Other proposal are listed on Wikidata:Wiktionary/Development --Pasleim (talk) 13:50, 8 February 2016 (UTC)
      To evaluate this proposal, I don't think it has an impact. Personally, I'm not sure what to think of it. If we come to the conclusion that we need this in a structured form, clearly Wiktionary (or Commons) can't provide it in a structured form. female form of label (P2521) seems to work out so far, even if we had the same type of opposing votes and users started building structured lists at Wikipedia instead.
      --- Jura 18:17, 8 February 2016 (UTC)
  •   Oppose. See http://www.unicode.org/cldr/charts/27/supplemental/language_plural_rules.html. Plural form as a monolingual text won't work for any language. Though in my opinion the idea of plural forms sound good, monolingual text does not suit it. The correct way might be a link to formatting template, which contains something like {{PLURAL:{{{1}}}|страница|страницы|страниц}}. But even that won't work for items with multiple snaks or qualifiers like sourcing circumstances (P1480). --Lockal (talk) 08:30, 12 February 2016 (UTC)
  •   Oppose will have to wait for structured wiktionary. Then we will have to create "plural form of female form", etc etc. I see no end to this. If that is accepted, I'd like to see a notice that this property will be migrated later so that people are aware of this. author  TomT0m / talk page 12:27, 12 February 2016 (UTC)

  Not done--Micru (talk) 13:52, 27 February 2016 (UTC)



Bore & Stroke

   Done: bore (P2556) (Talk and documentation)
DescriptionCylinder bore represents the size, in terms of diameter, of the cylinder in which a piston travels
Representsbore (Q245657)
Data typeQuantity
Template parameter"bore" in en:template:infobox_automobile_engine
Domainreciprocating engine (Q630010), compressors, other machines with pistons
Allowed values>0
ExampleWärtsilä-Sulzer RTA96-C (Q1625442) → 960 mm
Robot and gadget jobsconsistency check (positive number with distance unit), import from infoboxes


   Done: stroke (P2557) (Talk and documentation)
DescriptionLength of the motion in reciprocating engines and other mechanisms.
Representsstroke (Q671554)
Data typeQuantity
Template parameter"stroke" in en:template:infobox_automobile_engine
Domainreciprocating engine (Q630010), compressors, other machines with pistons
Allowed values>0
ExampleWärtsilä-Sulzer RTA96-C (Q1625442) → 2500 mm
Robot and gadget jobsconsistency check (positive number with distance unit), import from infoboxes
Motivation

Needed to systematically describe engine parameters Flukas (talk) 21:12, 22 February 2016 (UTC)

Discussion
  •   Support--Kopiersperre (talk) 08:24, 23 February 2016 (UTC)
  •   Comment Added stroke as one without the other does not really make sense.--Flukas (talk) 16:26, 23 February 2016 (UTC)
  •   Support both as proposed. Thryduulf (talk: local | en.wp | en.wikt) 17:25, 23 February 2016 (UTC)

  Done @Flukas, Kopiersperre, Thryduulf: --Micru (talk) 16:29, 27 February 2016 (UTC)

Wikidata usage instructions

Descriptiontext describing how to use a property or item
Data typeMonolingual text
Domainmainly properties, some items where needed
Examplemale (Q6581097) → Use with Property:P21 sex or gender. For groups of males use with subclass of (P279).
Motivation

This is being proposed as part of deleting/splitting comment (DEPRECATED) (P2315). Please see Wikidata:Properties_for_deletion#comment_.28P2315.29 for more information.

This was previously proposed at Wikidata:Property_proposal/Archive/44#property_usage. There were two reasons I can see for opposing it. The first reason being that the description field is sufficient. That is not true, it works when editing Wikidata directly, but it is inappropriate to include usage instructions in descriptions when showing descriptions in other contexts, see phab:T97566. Secondly, it was opposed because it was already covered by comment (DEPRECATED) (P2315). That is also not really true, the original description was quite vague and then the description was changed to be about usage instructions, but that is not what the property was intended for.

Ideally this property would be shown in search results when editing Wikidata (which is one of the suggested solutions to phab:T97566) so that usage instructions no longer need to be included in descriptions.

- Nikki (talk) 16:08, 24 February 2016 (UTC)

Discussion
  •   Support. Property labels should not contain usage instructions and this would seem a good way of storing those instructions. Thryduulf (talk: local | en.wp | en.wikt) 18:43, 24 February 2016 (UTC)
  •   Support I think getting usage instructions out of description is a good idea. I am a bit worried though about lack of internationalization, but that can be solved with qualifiers (e.g. P2439 (P2439)). --Laboramus (talk) 18:54, 24 February 2016 (UTC)
    • Monolingual text properties always have a language associated with each statement, so qualifiers wouldn't be necessary. :) - Nikki (talk) 19:02, 24 February 2016 (UTC)
  •   Support --188.175.125.38 19:15, 24 February 2016 (UTC)
  •   Support --Srittau (talk) 20:54, 24 February 2016 (UTC)
  •   Support We really must get usage instructions out of descriptions. They are completely confusing when viewed outside of the context of Wikidata. This seems like the only viable solution at this point. Kaldari (talk) 01:00, 25 February 2016 (UTC)
  •   Comment We might want to avoid replacing current usage of notes in descriptions with this before the software support its display in the edit GUI. P2315 is also used for uage notes on statements, not sure if this should cover both.
    --- Jura 08:42, 25 February 2016 (UTC)
  •   Support I don't really have a problem with usage instructions in descriptions - how it is to be used could be part of a description. However a separate property for this makes sense to me too. Any reason this isn't posted in Wikidata:Property_proposal/Property_metadata? Also I agree with Jura this would be nice to have displayed in the edit GUI (people don't always go to the property page when using a property). ArthurPSmith (talk) 18:59, 25 February 2016 (UTC)
    • I chose this subpage because it's not restricted to properties (even the example I used is an item, not a property). - Nikki (talk) 15:55, 27 February 2016 (UTC)

  Done @Nikki, Thryduulf, Laboramus, Srittau, Kaldari, ArthurPSmith:--Micru (talk) 17:15, 27 February 2016 (UTC)

comment

   Not done
Data typeMonolingual text
Domaineverything
Example 1MISSING
Example 2MISSING
Example 3MISSING
Motivation

This is being proposed as part of deleting/splitting comment (DEPRECATED) (P2315). Please see Wikidata:Properties_for_deletion#comment_.28P2315.29 for more information.

This property would be a generic comment property for people to add comments to things and would replace all the current uses of comment (DEPRECATED) (P2315), other than those which are usage instructions.

Although I'm proposing it, I don't actually support it for the reasons I gave in the deletion request, it's far too vague and we don't know what the comments are for nor who they are aimed at.

I think that in most cases, if people want to add generic comments about an item, the talk page would be sufficient. For cases where people want to narrow down the meaning of a statement, appropriate qualifiers should be used (or proposed, if there's nothing suitable already). For cases where people want to add custom edit summaries, while that isn't currently possible (see phab:T47224), I don't think it's appropriate to store those as part of the item's structured data anyway.

- Nikki (talk) 16:08, 24 February 2016 (UTC)

Discussion
  •   Oppose the correct usage of this property is too unclear. Anything that might be written in here would be better expressed through a more specific property (and if the right property doesn't exist, propose it). If something is needed as a stopgap, I agree that the Talk: page would suffice for that. SJK (talk) 07:50, 25 February 2016 (UTC)
  •   Oppose wikidata is about structured data. Comments add nothing in the way of structure. Who is the comment from? What does it imply about the item? Could be anything. Let's not add this please. ArthurPSmith (talk) 18:53, 25 February 2016 (UTC)

  Not done--Micru (talk) 13:54, 27 February 2016 (UTC)

WomenWriters ID

DescriptionIdentifiers in the Women Writers database of the Institute of Netherlands History (Q1665263)
Data typeString
Domainperson
Allowed valuesstring of letters and numbers
ExampleRijkje Bubbezon (Q1976101) → a86984df-a43a-4e12-bde2-f55e89c08cca
Sourcehttp://resources.huygens.knaw.nl/womenwriters
Formatter URLhttp://hdl.handle.net/11240/$1
Robot and gadget jobsWould be great to be included in Mix'n'Match
Motivation

Large online database of international women writers, maintained by a reputable Dutch research institute. Spinster (talk) 15:13, 7 November 2015 (UTC)

Discussion
  •   Support This one defnitely! Do we also need the other property for Orlando, or not? --Jane023 (talk) 10:06, 8 November 2015 (UTC)
  •   Support 7805 persons found! Multichill (talk) 11:56, 8 November 2015 (UTC)
  •   Support Runner1928 (talk) 20:00, 8 November 2015 (UTC)
  •   Support. Joe Filceolaire (talk) 08:16, 11 November 2015 (UTC)
  • @Spinster: The example link gives error 404 (Not Found). Fix it please. -- Sergey kudryavtsev (talk) 08:27, 11 December 2015 (UTC)
  • PLEASE HOLD. Thank you, Sergey, for being so watchful. What has happened? Apparently this website has gotten an overhaul and the old identifiers have disappeared (I only see a handle as permalink). The (identifier-like) string that links to the website's information page of a writer (example) is different from the string in the handle, which links to a structured metadata-like page (example).
  • Since we have a separate property for handle (Handle ID (P1184)), I'm not sure if we need this separate property anymore; on the other hand, for findability purposes I'd find it valuable to be able to search for women in this database separately via Wikidata (hence: a unique property for this dataset). If anyone has feedback on how to tackle this, I'd love to hear your input. (@Multichill: any ideas?) I'll contact the website managers to see if they have suggestions too. Spinster (talk) 09:05, 11 December 2015 (UTC)
  • Update - I received email from the maintainers of this database. The handles will be the permalinks indeed. I would like to stick to this property proposal; updated with the handle formatter URL.   Done Spinster (talk) 19:32, 2 February 2016 (UTC)
  •   Support --Edgars2007 (talk) 08:15, 3 February 2016 (UTC)
  • @Jane023: @Multichill: @Runner1928: @Filceolaire: @Sergey kudryavtsev: @Pigsonthewing: What do you think, now the proposal was updated? Spinster (talk) 13:20, 6 February 2016 (UTC)
    •   Support and I'd love to see further work on mapping the relations in this database to Wikidata properties. E.g., their 'has birth place' is our place of birth (P19). Runner1928 (talk) 02:38, 8 February 2016 (UTC)
@Spinster, Multichill, Runner1928, Filceolaire, Edgars2007, Jane023: -   Done ArthurPSmith (talk) 21:56, 8 February 2016 (UTC)

Nationalmuseum Sweden artist ID

DescriptionArtist identifier for Nationalmuseum in Sweden
Data typeExternal identifier
DomainPersons
Allowed values[0-9]\d{0,5} (1 to ~25000)
ExampleCarl Larsson (Q187310) → 3877
Sourceexternal reference
Formatter URLhttp://collection.nationalmuseum.se/eMuseumPlus?service=ExternalInterface&module=artist&objectId=$1
Robot and gadget jobsBot will populate most of these
Motivation

IDs used for artists in the Nationalmuseum artwork database. Useful both as external identifiers and for being able to match their artwork on Wikidata to artists André Costa (WMSE) (talk) 15:36, 21 January 2016 (UTC)

Discussion

Nationalmuseum Sweden artwork ID

DescriptionArtwork identifier for Nationalmuseum in Sweden
Data typeExternal identifier
DomainArtwork
Allowed values[0-9]\d{0,6} (1 to ~200000)
ExampleMidwinter's Sacrifice (Q761681) → 32534
Sourceexternal reference
Formatter URLhttp://collection.nationalmuseum.se/eMuseumPlus?service=ExternalInterface&module=collection&objectId=$1&viewType=detailView
Robot and gadget jobsBot will populate most of these
Motivation

IDs used for artwork in the Nationalmuseum artwork database. Useful both as external identifiers and for being able to match the artwork already on Wikidata to artists André Costa (WMSE) (talk) 15:47, 21 January 2016 (UTC)

Discussion

Box Office Mojo franchise ID

Descriptionidentifier of a film series or brand in the Box Office Mojo database
RepresentsBox Office Mojo (Q223142)
Data typeString
Domainfilm series (Q24856)
Allowed values[a-z0-9]+
ExampleMarvel Cinematic Universe (Q642878) → avengers
Sourcehttp://www.boxofficemojo.com/franchises/
Formatter URLhttp://www.boxofficemojo.com/franchises/chart/?id=$1.htm
Motivation

The database is a major source of box office data. See also Box Office Mojo film ID (former scheme) (P1237). Máté (talk) 21:07, 23 January 2016 (UTC)

Discussion

Box Office Mojo studio ID

Descriptionidentifier of a film studio in the Box Office Mojo database
RepresentsBox Office Mojo (Q223142)
Data typeString
Domainfilm studio (Q375336), film production company (Q1762059)
Allowed values[a-z0-9]+
ExampleWarner Bros. (Q126399) → warnerbros
Sourcehttp://www.boxofficemojo.com/studio/?view2=allstudios&p=.htm
Formatter URLhttp://www.boxofficemojo.com/studio/chart/?studio=$1.htm
Motivation

The database is a major source of box office data. See also Box Office Mojo film ID (former scheme) (P1237). Useful data are available on the yearly and all time financial performance of the studios' products. Máté (talk) 21:07, 23 January 2016 (UTC)

Discussion

Aarne–Thompson–Uther Tale Type Index

Descriptionindex used to classify folktales
RepresentsAarne–Thompson–Uther classification system (Q301545)
Data typeString
Template parameter"Aarne-Thompson Grouping" in en:template:Infobox folk tale
Domainfolk tale (Q1221280)
Allowed valuesnumbers between 1 and ca. 2499, optional suffixes like A, B, C (the AT groupings are preceded with "AT")
ExampleCinderella (Q11841) → 510 A
SourceMultilingual Folk Tale Database
Formatter URLhttp://www.mftd.org/index.php?action=atu&act=select&atu=$1
Motivation

Aarne-Thompson classification systems are used to classify folk tales. The system is used in comparative folkloristics to identify some 2500 basic plots. I believe the expanded Aarne-Thompson-Uther (ATU) classification would be preferred to the old AT system, though it could be advantageous to be able to accept either. gobonobo + c 01:35, 3 February 2016 (UTC)

Discussion
  •   Support This is a global standard. I will follow up with a few notes which may be useful to property implementers. Phil wink (talk) 04:35, 3 February 2016 (UTC)
    • Although, as I understand it, "Aarne-Thompson-Uther grouping" is unambiguous, "Aarne-Thompson grouping" might refer to 2 distinct indices: (1) the Aarne–Thompson Motif-Index or (2) the Aarne–Thompson Tale Type Index. It is the update to #2 which we're talking about here. So just to be explicit it may be best to re-name this property Aarne–Thompson–Uther Tale Type Index.
    • We are right to use ATU (the new standard), but I think we are justified in porting A-T numbers (the previous version) directly into this ATU property. It is intended to be "backwards-compatible", and my understanding is that it almost totally is.
    • The ATU index is organized hierarchically. I'm not sure this is easily managed in Wikidata structure; however I'll include here the keyed tables I'd use if I were setting this up as a relational database (this comes from the outline at Multilingual Folk Tale Database noted above, but normalized). The actual ATU values we'll be storing in this property would constitute "Level 4" (not tabulated). Maybe someone can make something of this... Phil wink (talk) 05:00, 3 February 2016 (UTC)
ATU Level 1
L1 RUBRIC Range
1 ANIMAL TALES 1-299
2 TALES OF MAGIC 300-749
3 RELIGIOUS TALES 750-849
4 REALISTIC TALES 850-999
5 TALES OF THE STUPID OGRE (GIANT, DEVIL) 1000-1199
6 ANECDOTES AND JOKES 1200-1999
7 FORMULA TALES 2000-2399
ATU Level 2
L1 L2 RUBRIC Range
1 1 Wild Animals 1-99
1 2 Wild Animals and Domestic Animals 100-149
1 3 Wild Animals and Humans 150-199
1 4 Domestic Animals 200-219
1 5 Other Animals and Objects 220-299
2 6 Supernatural Adversaries 300-399
2 7 Supernatural or Enchanted Wife (Husband) or Other Relative 400-459
2 8 Supernatural Tasks 460-499
2 9 Supernatural Helpers 500-559
2 10 Magic Objects 560-649
2 11 Supernatural Power or Knowledge 650-699
2 12 Other Tales of the Supernatural 700-749
3 13 God Rewards and Punishes 750-779
3 14 The Truth Comes to Light 780-799
3 15 Heaven 800-809
3 16 The Devil 810-826
3 17 Other Religious Tales 827-849
4 18 The Man Marries the Princess 850-869
4 19 The Woman Marries the Prince 870-879
4 20 Proofs of Fidelity and Innocence 880-899
4 21 The Obstinate Wife Learns to Obey 900-909
4 22 Good Precepts 910-919
4 23 Clever Acts and Words 920-929
4 24 Tales of Fate 930-949
4 25 Robbers and Murderers 950-969
4 26 Other Realistic Tales 970-999
5 27 Labor Contract 1000-1029
5 28 Partnership between Man and Ogre 1030-1059
5 29 Contest between Man and Ogre 1060-1114
5 30 Man Kills (Injures) Ogre 1115-1144
5 31 Ogre Frightened by Man 1145-1154
5 32 Man Outwits the Devil 1155-1169
5 33 Souls Saved from the Devil 1170-1199
6 34 Stories about a Fool 1200-1349
6 35 Stories about Married Couples 1350-1439
6 36 Stories about a Woman 1440-1524
6 37 Stories about a Man 1525-1724
6 38 Jokes about Clergymen and Religious Figures 1725-1849
6 39 Anecdotes about Other Groups of People 1850-1874
6 40 Tall Tales 1875-1999
7 41 Cumulative Tales 2000-2100
7 42 Catch Tales 2200-2299
7 43 Other Formula Tales 2300-2399
ATU Level 3
L1 L2 L3 RUBRIC Range
1 1 1 The Clever Fox (Other Animal) 1-69
1 1 2 Other Wild Animals 70-99
1 2 3 Wild Animals and Domestic Animals 100-149
1 3 4 Wild Animals and Humans 150-199
1 4 5 Domestic Animals 200-219
1 5 6 Other Animals and Objects 220-299
2 6 7 Supernatural Adversaries 300-399
2 7 8 Wife 400-424
2 7 9 Husband 425-449
2 7 10 Brother or Sister 450-459
2 8 11 Supernatural Tasks 460-499
2 9 12 Supernatural Helpers 500-559
2 10 13 Magic Objects 560-649
2 11 14 Supernatural Power or Knowledge 650-699
2 12 15 Other Tales of the Supernatural 700-749
3 13 16 God Rewards and Punishes 750-779
3 14 17 The Truth Comes to Light 780-799
3 15 18 Heaven 800-809
3 16 19 The Devil 810-826
3 17 20 Other Religious Tales 827-849
4 18 21 The Man Marries the Princess 850-869
4 19 22 The Woman Marries the Prince 870-879
4 20 23 Proofs of Fidelity and Innocence 880-899
4 21 24 The Obstinate Wife Learns to Obey 900-909
4 22 25 Good Precepts 910-919
4 23 26 Clever Acts and Words 920-929
4 24 27 Tales of Fate 930-949
4 25 28 Robbers and Murderers 950-969
4 26 29 Other Realistic Tales 970-999
5 27 30 Labor Contract 1000-1029
5 28 31 Partnership between Man and Ogre 1030-1059
5 29 32 Contest between Man and Ogre 1060-1114
5 30 33 Man Kills (Injures) Ogre 1115-1144
5 31 34 Ogre Frightened by Man 1145-1154
5 32 35 Man Outwits the Devil 1155-1169
5 33 36 Souls Saved from the Devil 1170-1199
6 34 37 Stories about a Fool 1200-1349
6 35 38 Stories about Married Couples [other] 1350-1379
6 35 39 The Foolish Wife and Her Husband 1380-1404
6 35 40 The Foolish Husband and His Wife 1405-1429
6 35 41 The Foolish Couple 1430-1439
6 36 42 Stories about a Woman [other] 1440-1449
6 36 43 Looking for a Wife 1450-1474
6 36 44 Jokes about Old Maids 1475-1499
6 36 45 Other Stories about Women 1500-1524
6 37 46 The Clever Man 1525-1639
6 37 47 Lucky Accidents 1640-1674
6 37 48 The Stupid Man 1675-1724
6 38 49 The Clergyman is Tricked 1725-1774
6 38 50 Clergyman and Sexton 1775-1799
6 38 51 Other Jokes about Religious Figures 1800-1849
6 39 52 Anecdotes about Other Groups of People 1850-1874
6 40 53 Tall Tales 1875-1999
7 41 54 Chains Based on Numbers, Objects, Animals, or Names 2000-2020
7 41 55 Chains Involving Death 2021-2024
7 41 56 Chains Involving Eating 2025-2028
7 41 57 Chains Involving Other Events 2029-2075
7 41 58 Cumulative Tales [other] 2076-2100
7 42 59 Catch Tales 2200-2299
7 43 60 Other Formula Tales 2300-2399
Per the suggestion, I've renamed the property to Aarne–Thompson–Uther Tale Type Index. gobonobo + c 05:16, 3 February 2016 (UTC)

Acceptable daily intake (ADI)

DescriptionEstimate by JECFA of the amount of a food additive, expressed on a body weight basis, that can be ingested daily over a lifetime without appreciable health risk.
Representsacceptable daily intake (Q680142)
Data typeNumber (not available yet)
Domainfood additive
Allowed valuesnumbers with units in amount per kilo
Examplepentachlorobenzene (Q425468): 0.0167 mg/kg
SourceExternal references like toxnet
Motivation

Provide full set of toxicological data. Snipre (talk) 12:50, 11 February 2016 (UTC)

Discussion
  Support Basic toxicological properties such as this should be added to Wikidata. It would bring more health-relevant information to chemical properties. It would also make easier to find and compare toxicity of different chemicals. Tolerable daily intake (TDI), limit value, and some other properties could be added as well. --Jtuom (talk) 14:52, 29 January 2016 (UTC)
  Support Interesting information. Will be useful to Open Food Facts, which is also linked to Wikidata. --Teolemon (talk) 12:34, 11 February 2016 (UTC)
@Snipre, Jtuom, Teolemon: -   Done! ArthurPSmith (talk) 19:54, 19 February 2016 (UTC)

Global-warming potential

Descriptionheat trapped by a certain gas in CO2 equivalents
Representsglobal warming potential (Q901028)
Data typeNumber (not available yet)
Template parameter"GWP" in Infobox Chemikalie
Domainchemical compound (Q11173) and mixture (Q169336)
Allowed valuesnumber with year as unit
Exampletrichloromonofluoromethane (Q423000) → 5352, duration (P2047): 100 year
SourceGlobal warming potentials and radiative efficiencies of halocarbons and related compounds (doi:10.1002/rog.20013) or IPCC Fifth Assessment Report (Q3429705) Supplementary Material ([8])
Motivation

GWP for 100 years.--Kopiersperre (talk) 13:54, 31 January 2016 (UTC)

Discussion
  •   Question Would a single property with a duration qualifier work better here? Thryduulf (talk: local | en.wp | en.wikt) 20:28, 31 January 2016 (UTC)
In nearly all cases in German Wikipedia the GWP is given for 100 years. But for completeness I added also the 20 years value.
If every duration would be possible, of course the qualifier approach would fit better. Because of the benefit of much easier querying I would urge to create two properties here.--Kopiersperre (talk) 23:37, 31 January 2016 (UTC)
  Support I support this property but I agree with Thryduulf that there should be a generic property Global warming potential, for which the duration is specified as a qualifier. As many GWPs are given for 100 years, it might be possible to create a sub-property which already has the duration 100 years embedded. But I would add this generic property rather than another specific GWP for 20 years. --Jtuom (talk) 11:29, 2 February 2016 (UTC)
  Comment I would support a generic property with duration as qualifier. Snipre (talk) 21:34, 2 February 2016 (UTC)
  •   Support GWP 100 years; data may be taken from Table 8.SM.16 of the Fifth Assessment Report of the IPCC. --Leyo 22:19, 11 February 2016 (UTC)
  •   Support for the single property using duration (P2047) as qualifier if duration is different from 100 years (default to 100 as that seems a standard). We have a similar issue with natural abundance (P2374) - that is defined to give the average value in Earth's crust without a qualifier, or other location with qualifier. I believe that would be the right way to handle this one. ArthurPSmith (talk) 21:04, 18 February 2016 (UTC)
  • @Kopiersperre: Do you agree to change the proposal ? We have enough support to create a modified version of the property based on qualifier to define time scale. Snipre (talk) 07:50, 22 February 2016 (UTC)
    • @Snipre: First I would like know how to query the GWP with duration as qualifier by WDQ.--Kopiersperre (talk) 07:56, 22 February 2016 (UTC)
@Kopiersperre: Here is an example of SPARQL query of chemicals having a density value defined at a temperature above 20°C (temperature is defined as qualifier of density):
</PREFIX wd: <http://www.wikidata.org/entity/> PREFIX wdt: <http://www.wikidata.org/prop/direct/> PREFIX wikibase: <http://wikiba.se/ontology#> PREFIX p: <http://www.wikidata.org/prop/> PREFIX ps: <http://www.wikidata.org/prop/statement/> PREFIX pq: <http://www.wikidata.org/prop/qualifier/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?chem ?den ?temp WHERE { ?chem wdt:P31 wd:Q11173 . ?chem wdt:P2054 ?den . ?chem p:P2054 ?denT . ?denT pq:P2076 ?temp filter(?temp > 20) . }
No idea for WDQ. By the way WDQ supports qualifiers filter (see doc), so I think you can build easily the query, something like claim[2054]{quantity[2076,100]}. Snipre (talk) 13:55, 22 February 2016 (UTC)
Ok, let's create the property. May you also take a look at this?--Kopiersperre (talk) 15:34, 22 February 2016 (UTC)
@Kopiersperre: I answered you on my french talkpage. Snipre (talk) 20:08, 23 February 2016 (UTC)
  Support Snipre (talk) 19:28, 22 February 2016 (UTC)
@Micru, ArthurPSmith, Danrok, Jura1, Tobias1984: Please create this property. Snipre (talk) 13:20, 29 February 2016 (UTC)
  Done this one. I leave the other to an admin or one of the above.
--- Jura 13:48, 29 February 2016 (UTC)

Global-warming potential (20 years)

   Not done
Descriptionheat trapped by a certain gas in CO2 equivalents
Representsglobal warming potential (Q901028)
Data typeNumber (not available yet)
Template parameter"GWP" in Infobox Chemikalie
Domainchemical compound (Q11173) and mixture (Q169336)
Exampletrichloromonofluoromethane (Q423000) → 7020
SourceGlobal warming potentials and radiative efficiencies of halocarbons and related compounds (doi:10.1002/rog.20013) or IPCC Fifth Assessment Report (Q3429705) Supplementary Material ([9])
Motivation

GWP for 20 years.--Kopiersperre (talk) 13:54, 31 January 2016 (UTC)

Discussion

ECHA InfoCard ID

DescriptionEuropean Chemicals Agency (Q48798) puts together the most relevant information on individual chemical substances in so-called InfoCards.
Data typeExternal identifier
Domainchemical compound (Q11173) & mixture (Q169336)
Allowed valuesregexp: [0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]
Examplediethylhexyl phthalate (Q418492) → 100.003.829
SourceECHA's list of registered substances (left column with link to InfoCard) → wikitable of that list
Formatter URLhttp://echa.europa.eu/substance-information/-/substanceinfo/$1
Motivation

ECHA's document What is an Infocard? states the following (shortened):
In accordance with ECHA’s legal obligations to make (non-confidential) information on chemicals publicly available, the InfoCard serves as a high-level summary for a broad public, consisting of information that is most relevant to an audience of consumers, downstream users and professionals active in the chemical industry. ECHA aims to enhance the safe handling of chemicals for humans and the environment.
In addition to linking to the InfoCard (example), the same ID might potentially be used to link to other database entries, e.g.:

--Leyo 00:46, 19 February 2016 (UTC)

Discussion
  Support The unique way to connect to ECHA database. Snipre (talk) 04:40, 19 February 2016 (UTC)
  Support I like the information about the tonnage band much.--Kopiersperre (talk) 08:23, 19 February 2016 (UTC)
@Micru, ArthurPSmith, Danrok, Jura1, Tobias1984: Please create this property. Snipre (talk) 13:21, 29 February 2016 (UTC)
@Snipre, Leyo, Kopiersperre:: Property has been created. Mbch331 (talk) 19:51, 29 February 2016 (UTC)

defining formula

Descriptionformula representing a theorem or law
Data typeMathematical expression
DomainMathematical and physics based articles
Allowed valuesLaTeX strings
ExamplePythagorean theorem (Q11518) => "a^2 + b^2 = c^2", mass–energy equivalence (Q35875) => "E = m c^2"
Motivation

Every mathematical and physical article defining a theorem or law has at least one formula, which defines the item. – The preceding unsigned comment was added by Physikerwelt (talk • contribs) at 9 feb 2016 21:35‎ (UTC). PS: I did not write the request but copied it from https://phabricator.wikimedia.org/T126369 --Physikerwelt (talk) 18:51, 10 February 2016 (UTC)

Discussion

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha  Notified participants of WikiProject Mathematics Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
  Notified participants of WikiProject Physics

  Support - Mbch331 (talk) 13:20, 10 February 2016 (UTC)
  Support Necessary. -- LaddΩ chat ;) 13:29, 10 February 2016 (UTC)
  Oppose Use TeX string (P1993). Snipre (talk) 15:42, 10 February 2016 (UTC)
TeX string (P1993) shows the plain tex string, this property will show the formula formatted as a math formula:  . Mbch331 (talk) 17:47, 10 February 2016 (UTC)
I think it's reasonable to discuss both (changing the value type of TeX string (P1993) and adding this new data type with slighly different semantics) options. By the way Wikibase uses MathML rendering i.e.   --Physikerwelt (talk) 18:51, 10 February 2016 (UTC)
Mediawiki seems to use their own flavor of LaTeX; see this link. -- LaddΩ chat ;) 17:00, 11 February 2016 (UTC)
@Laddo: you are absolutly right. My comment was just about a technical detail, how the input is displayed on the screen. With Firefox, you get MathML rendering, but certainly you would type $a^2 + b^2 = c^2$.--Physikerwelt (talk) 19:40, 14 February 2016 (UTC)
There is a new data type 'Mathematical Expression'. In contrast to the property 'TeX string' (which is just a plain string) the new data type comes with a validator to permit formula input only. And it includes a formatter to show the formula rendered (by MathML) and not as plain TeX code. That's more specific than just having mathematical expressions as plain TeX strings without any functionality behind. --JulianHilbig (talk) 19:51, 14 February 2016 (UTC)
  Support – T.seppelt (talk) 18:43, 14 February 2016 (UTC)
  Support - JulianHilbig (talk) 19:06, 14 February 2016 (UTC)
  Support --LlinhTran (talk) 20:11, 14 February 2016 (UTC)
We should delete TeX string then. --Izno (talk) 12:38, 15 February 2016 (UTC)

Mathematical formula

   Withdrawn
Descriptionformula to calculate. Use variables, figures, and the following ASCII elements: */-+^. For more complex formula, use TeX (P1993)
Representsformula (Q976981)
Data typeString
Allowed values/*-+^ et variables
Examplev = d/t (Q21600451) → v = d/t
Robot and gadget jobsimport de Wikipédia
Motivation

Permet la définition de formules simples et leur import de Wikipédia. --- Jura 10:56, 15 December 2015 (UTC)

Discussion
  •   Support --- Jura 10:56, 15 December 2015 (UTC)
    • You have been told repeatedly that you do not need to support your own proposals. Also, please provide a label and description in English. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 15 December 2015 (UTC)
      • IMO, English labels/descriptions for proposals are not at all mandatory. This is not an exclusively English-language project. --Yair rand (talk) 21:30, 15 December 2015 (UTC)
        • Who said they were mandatory? We've been over this before; and Jura1 has apparently functional English. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:46, 15 December 2015 (UTC)
          • This is off-topic and redundant. Please use the talk page to discuss this stuff. The header already requests users to translate this into other languages. If the Royal Society of Chemistry is interested in translation services, I think the should hire corresponding services and not send their resident to ask volunteers to do this. If this keeps being an issue, I think we should ask WMF to make this clear to the Royal Society of Chemistry. --- Jura 10:39, 16 December 2015 (UTC)
            • It is - unlike your utterly bizarre comments about the RSC - not off topic; nor is it redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:09, 16 December 2015 (UTC)
              • I don't expect you to agree with this. Can you clarify how your editorial activity at Wikidata is linked to the Royal Society of Chemistry? Does the Royal Society of Chemistry endorsed and/or support and/or sponsor your editorial activity here? --- Jura 15:41, 16 December 2015 (UTC)
  •   Oppose as proposed. The formula in the example should be an attribute of Category:Velocity (Q9944516). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:55, 15 December 2015 (UTC)
  • Oppose because of the substantial overlap with the TeX property. --Izno (talk) 17:54, 28 December 2015 (UTC)
    • That is a good point. If the TeX format is kept simple it matches the above. For other things, TeX is needed anyways. --- Jura 10:12, 29 December 2015 (UTC)
  •   Support I have suggested it under the "natural sciences" category. To get on topic: Already existing support for TeX is irrelevant, I want/need a string that's easily retrievable and parsable that can actually be calculated with and is somewhat humanreadable. TeX does not fulfil that function since it parsing it is more complicated and in general needs knowledge of TeX formatting to be understood.  – The preceding unsigned comment was added by 141.23.124.250 (talk • contribs).
    "Already existing support for TeX is irrelevant," is an unsubstantiated claim. It is entirely relevant.

    "I want" The key phrase, because "need" for a suitable string providing the formula of a particular conversion (or otherwise) has already been provided for in the use of TeX.

    "easily retrievable" Regardless these strings are "easily" retrievable.

    "[easily] parsable" may be the only interesting concern. But already I see an issue: "()" are not provided for in the proposal (c.f. a / (b + c)). How many other "easily parsable" characters are missing from the set? Underscore is certainly one; what happens with the need to differentiate between two speeds (as in Mach number (Q160669))? How quickly does that set increase to "not parsable anymore"? Lowest common denominator doesn't work.

    "calculated with" I presume proper TeX can provide this as well, so the point seems irrelevant.

    "somewhat humanreadable." doesn't seem like a huge concern, whatsoever. For the operators provided, there are suitable TeX, none of which can be said to be particularly not-human-readable. --Izno (talk) 13:06, 12 January 2016 (UTC)

  • Maybe we could try to focus on assessing the user's need rather than pick on their wording or formatting .. I'm sure everyone loves TeX, but maybe there are other options. Possibly the new formula datatype can cover some of it, but it is essentially TeX based.
    --- Jura 10:02, 13 January 2016 (UTC)
  •   Comment I changed the datatype to "formula" (might be available soon).
    --- Jura 11:56, 31 January 2016 (UTC)
  •   Comment I would like to see some more/different examples of how this would be used. The present example is simply an entity that happens to already be a mathematical formula, so I don't see how this property adds much in that case. What other examples would be good illustrations of how this property should be used? ArthurPSmith (talk) 14:13, 11 February 2016 (UTC)
    • for example this proposal for "defining formula" has some excellent examples. Maybe these two proposals should be merged, though perhaps they also are intended to have different meanings; it's not clear to me from this proposal if it's supposed to be something distinct or not. ArthurPSmith (talk) 14:15, 11 February 2016 (UTC)
  Oppose duplicate of defining formula (P2534) --Pasleim (talk) 15:42, 22 February 2016 (UTC)
  •   Withdrawn We need an alternative to TeX, but the new datatype is just the same as we already had with the TeX property.
    --- Jura 13:38, 27 February 2016 (UTC)

equation

   Withdrawn
Descriptionequation describet by the item
Representsequation (Q11345)
Data typeMathematical expression
Domainitems from Category:Equations (Q7156671)
ExampleArrhenius equation (Q507505) →   (see test)
Sourceusually Wikipedia articles
Motivation

Many Wikipedia articles describe equations: now we can write them with an appropriate property. Epìdosis 16:51, 11 February 2016 (UTC)

Discussion

Duplicate of defining formula (P2534), this would be useless. --Epìdosis 14:43, 17 February 2016 (UTC)


amended by (en) / поправки в (ru)

   Done: amended by (P2567) (Talk and documentation)
DescriptionDocument is amended by specified other document.
Data typeItem
Domaindocuments, legislative_enactments.
Allowed values(see above)
Robot and gadget jobsTracking and search.
Proposed bySfan00 IMG (talk)

This property is intended to note amendments made to a document by another document Sfan00 IMG (talk) 14:35, 4 August 2013 (UTC)

Should this property proposal, and the following one also, be moved to a different section? I don't see that they are relevant to Wikisource as I have not seen many examples of these properties being recorded on Wikisource in a structured way (e.g. s:Copyright Act, 1956 (United Kingdom)), however they are part of the large set of attributes needed for w:Template:Infobox legislation. John Vandenberg (talk) 09:28, 30 November 2013 (UTC)

repealed by (en)

   Done: repealed by (P2568) (Talk and documentation)
DescriptionDocument is repealed/inactived by specified other document.
Data typeItem
Domaindocuments, legislative_enactments.
Allowed values(see above)
Robot and gadget jobsTracking and search.
Proposed bySfan00 IMG (talk)

This property is intended to note ammendments made to a document by another document..

Contact times of eclipses

   Done: no label (P2569) (Talk and documentation)
DescriptionContact times of eclipses: P1, U1, U2, U3, U4, P4
Data typePoint in time
Domainlunar and solar eclipses
Allowed valuestime in UTC
Example6 April 2015, 03:22 UTC. qualifier <applies to part:U4 - solar eclipse>
SourceWikipedia list article, e.g. en:List of 21st-century lunar eclipses
I have amended the example as I understand it should be used. Please check I got it right.
Can this property be extended so it can be used on solar eclipses as well? Creating a property that can only be used on lunar eclipses seems a bit narrow. Filceolaire (talk) 00:10, 29 April 2015 (UTC)
Yes, I believe this is correct (see en:Solar eclipse of August 11, 1999#Notable times and coordinates for example. I will ask someone more knowledgeable to comment here. MSGJ (talk) 09:52, 29 April 2015 (UTC)
P1-4 and U1-4 apply to solar and lunar eclipses, but differently. A solar eclipse is a en:Transit (astronomy) so the timing is based on the viewing location INSIDE a shadow, while a lunar eclipse has viewers looking at an object INSIDE a shadow, so everyone sees the same appearance at the same universal time. So knowing the P1-4,U1-4 times for a solar eclipse are less useful for any given observer. Tomruen (talk) 01:08, 30 April 2015 (UTC)
If U4 for a solar eclipse is different from U4 for a lunar eclipse then we should have separate items for these with the "applies to part" qualifier linking to the appropriate item in each case. This means this property could be used for solar eclipses if we just change the label. I would   Support this property if you made this change to the property label and description. Filceolaire (talk) 03:04, 30 April 2015 (UTC)
Could you explain what you mean by "This means this property could be used for solar eclipses if we just change the label." Does that mean that properties can have more than one label? Or do you mean that you could have two statements for "subject item of this property"? Or do you mean something else? MSGJ (talk) 12:24, 30 April 2015 (UTC)
Rename the property as "Contact time for eclipses". Change the description to "Contact time for lunar and solar eclipses (U1, U2 etc. lunar and U1, U2 etc. solar)". Filceolaire (talk) 16:41, 30 April 2015 (UTC)
  Done, although no corresponding items created yet MSGJ (talk) 09:22, 5 June 2015 (UTC)
I ammended the example a little. I think this is good now and support - as my comment above. Joe Filceolaire (talk) 16:48, 12 September 2015 (UTC)

Saros cycle of eclipse

   Done: no label (P2570) (Talk and documentation)
Representssaros cycle (Q220397)
Data typeNumber (not available yet)
Domainlunar/solar eclipses
Allowed valuesa whole number between -20 and 183
ExampleJune 2029 lunar eclipse (Q6312134) => 130
SourceWikipedia list article, e.g. en:List of 21st-century lunar eclipses
Discussion

These properties are for describing lunar eclipses. I understand that times are not yet possible, so these can be put on hold if approved.

Proposed by: MSGJ (talk)

@MSGJ: please provide labels for each proposal individually. Josh Baumgartner (talk) 23:02, 20 April 2015 (UTC)
@Joshbaumgartner: Hi Josh, do you have any comments on the merits of this proposal? MSGJ (talk) 11:51, 28 April 2015 (UTC)
@MSGJ: On the surface they seem appropriate, but my concern was more administrative in nature. A nice clear label and description for each of the requested properties makes it much easier for a property creator to do the actual creation of your request once consensus is gained. Josh Baumgartner (talk) 20:27, 28 April 2015 (UTC)
  Support useful to describe lunar (and solar) eclipses. --Pasleim (talk) 07:52, 26 April 2015 (UTC)
Please provide a description, and the item to which the example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 14 July 2015 (UTC)
Generally   Support. Would this include both Saros (and member) 130 (49 of 72) as the template currently does? --Mu301 (talk) 22:27, 5 February 2016 (UTC)

uncertainty corresponds to

Description...
Data typeItem
Domainqualifier to number datatype-properties
Allowed values1 sigma/3 sigma etc
Exampleorbital eccentricity (P1096):0.8524512679233956; 1 sigma:0.00028691 q:uncertainty corresponds to: 1 sigma
Sourceexternal references
1 Sigma proposal (archived at pp/archive/39)
   Not done
DescriptionA property to be used as qualifier, when the precision is described with standard deviation (Q159375) instead of +/- whatever
Representsstandard deviation (Q159375)
Data typeNumber (not available yet)
Domainas a qualifier to (almost) any number-datatype property
Exampleorbital eccentricity (P1096):0.8524512679233956; 1 sigma:0.00028691 [10]
Format and edit filter validationthe unit of this qualifier should be the same as the unit for the claim itself
Sourceexternal reference
Motivation

We need alternatives to the present datamodel for precision. Not all sources gives you information about the precison in terms of +/-X. For those cases is this maybe a solution. Innocent bystander (talk) 18:55, 20 October 2015 (UTC)

Discussion

Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
  Notified participants of WikiProject Physics Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Denise Slenter
Daniel Mietchen
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Sebotic
Netha
Hugo
Samuel Clark
Tris T7
Leiem
Christianhauck
SCIdude
Binter
Photocyte
Robert Giessmann
Cord Wiljes
Jonathan Bisson
GrndStt
Ameisenigel
Charles Tapley Hoyt
ChemHobby
Peter Murray-Rust
Erfurth
  Notified participants of WikiProject Chemistry Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha  Notified participants of WikiProject Mathematics

  • What about saying "uncertainty corresponds to" (or "+- corresponds to"). It would be item-datatype and could link to 1-sigma, 2-sigma, etc. Otherwise I think many people will use +-0 for numbers and only add the uncertainty in the qualifiers. --Tobias1984 (talk) 09:28, 28 October 2015 (UTC)
    What about the following changes in your example above?
    orbital eccentricity (P1096): 0.8524512679233956 ± 0.00028691 (1 sigma)
    orbital eccentricity (P1096): 0.8524512679233956 ± 0.00028691 (1 σ)
    --Leyo 09:43, 28 October 2015 (UTC)
  Oppose I would be in favor of an "uncertainty" property for qualifiers as suggested by Tobias1984 above, with various items as target (standard deviation, 2-sigma, or whatever else is commonly used). I don't think "1 sigma" makes sense as a property in itself. ArthurPSmith (talk) 13:22, 28 October 2015 (UTC)
  Oppose Also, uncertainties can be one-sided, such as the half-lives of ununoctium-294 and other highly radioactive elements, in which case this does not make sense.--Jasper Deng (talk) 16:31, 2 November 2015 (UTC)
@Jasper Deng: I never proposed that this property should be used in every case, only when the numbers in the sources fits this solution. Anyhow, I have marked this as "Not done", since I agree with the objections above. -- Innocent bystander (talk) 17:34, 2 November 2015 (UTC)

  Archived Josh Baumgartner (talk) 22:07, 18 November 2015 (UTC)

Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
  Notified participants of WikiProject Physics Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Denise Slenter
Daniel Mietchen
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Sebotic
Netha
Hugo
Samuel Clark
Tris T7
Leiem
Christianhauck
SCIdude
Binter
Photocyte
Robert Giessmann
Cord Wiljes
Jonathan Bisson
GrndStt
Ameisenigel
Charles Tapley Hoyt
ChemHobby
Peter Murray-Rust
Erfurth
  Notified participants of WikiProject Chemistry Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha  Notified participants of WikiProject Mathematics

Motivation

The objections agains my proposed "1 sigma"-property above makes sense. @Tobias1984, ArthurPSmith: I propose this property instead. Innocent bystander (talk) 11:50, 2 November 2015 (UTC)

Discussion
@Innocent bystander: Thanks for taking the lead on this. This proposal seems very workable. Should we also propose another qualifier for "distribution type = normal distribution (Q133871)"? 1 Sigma for the Gauss Distribution is 68.27 %, but I am not sure if that is true for all distributions. --Tobias1984 (talk) 12:22, 2 November 2015 (UTC)
@Innocent bystander: Your solution is interesting but you have to propose a global solution including probability distribution ( normal, lognormal,...) and absolute or relative values. Snipre (talk) 13:02, 2 November 2015 (UTC)
  •   Support. sounds good to me! To clarify - the allowed value should probably be an item (we do have standard deviation (Q159375) which is ok for 1 sigma, but I think we'd have to add items for 2 sigma, 3 sigma, etc. ?)

  Done @Innocent bystander, Tobias1984, Snipre: Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
  Notified participants of WikiProject Physics. Please, create the items for 2-sigma, 3-sigma, etc. as needed.--Micru (talk) 17:14, 1 March 2016 (UTC)

Köppen climate classification

Descriptionindicates the characteristic climate of a place (Köppen climate classification).
RepresentsKöppen climate classification (Q124095)
Data typeItem
Template parameterClimate
DomainAny city, region, country, etc.
Allowed valuesOne of the symbols of the Köppen climate classification.
ExampleSan Francisco (Q62) → warm-summer Mediterranean climate (Q21578284)
SourceClimate chart of the Wikipedia article of the place.
Robot and gadget jobsBots could create this property (looking at the existing climate charts on the English Wikipedia) and add it to the infoboxes/climate charts in other editions.
Motivation

This would be the first step. The next one would be to add the whole climate data with the average temperatures and rainfall inches. It would be really easy to translate the climate data template in any language, or to build apps ("tell me how's the weather like in SF in October"). A455bcd9 (talk) 21:40, 12 November 2015 (UTC)

Discussion

  Done @A455bcd9, AmaryllisGardener, Joshbaumgartner, Mrwojo, Pigsonthewing:@Pasleim, Thryduulf, Ben1978, Thierry Caro, Nikki:--Micru (talk) 14:12, 28 February 2016 (UTC)

@A455bcd9: May you please first create items and translations for all Köppen zones?--Kopiersperre (talk) 14:34, 28 February 2016 (UTC)

Wikidata Zone English German Your language
A tropical climate Tropische Klimate
Af tropical rainforest climate tropisches Regenwaldklima
Am tropical monsoon climate Regenwaldklima trotz Trockenzeit
Aw tropical savanna climate Savannenklima (wintertrocken)
arid (Q1330709) B dry climate Trockenklimate
desert climate (Q190946) BW desert climate Wüstenklima
BWh hot desert climate
BWk cold desert climate
BS Steppenklima
BSh hot semi-arid climate
BSk cold semi-arid climate
C Warmgemäßigte Klimate
Mediterranean climate (Q13996) Cs Mediterranean climate Etesienklima (sommertrocken)
Csa hot-summer Mediterranean climate mediterranes Klima mit heißem Sommer
warm-summer Mediterranean climate (Q21578284) Csb warm-summer Mediterranean climate mediterranes Klima mit warmem Sommer
Cw sinisches Klima (wintertrocken)
Cwa humid subtropical climate
Cwb subtropical highland climate wintertrockenes Klima mit warmem Sommer
Cwc subtropical highland climate
Cf feuchtgemäßigtes Klima
Cfa humid subtropical climate feuchtgemäßigtes Klima mit heißem Sommer
oceanic climate (Q182090) Cfb oceanic climate ozeanisches Klima
Cfc subpolar oceanic climate kaltes ozeanisches Klima
D Boreale Klima oder Schneewaldklimate
Dsa continental Mediterranean climate
Dsb continental Mediterranean climate
Dsc subarctic climate
Dsd subarctic climate
Dw transsibirisches Klima (wintertrocken)
Dwa humid continental climate
Dwb humid continental climate
Dwc subarctic climate
Dwd subarctic climate
Df immerfeucht
Dfa humid continental climate
Dfb humid continental climate
Dfc subarctic climate
Dfd subarctic climate
E Eisklimate jenseits der Baumgrenze oder Schneeklimate
tundra climate (Q23662321) ET tundra climate Tundrenklima
EF ice cap climate Klima des ewigen Frostes

mentioned in

   Not done
DescriptionSimilar property to present in work (P1441) but for items that are only named in a work but not actually present in it.
Data typeItem
Domainfictional item (fictional character (Q95074), fictional location (Q3895768), fictional object (Q15706911)…)
Allowed valueswork (Q386724) source = infoboxes
ExampleBeren Erchamion (Q725935) => The Lord of the Rings (Q15228)
Format and edit filter validation(exemple : 7 chiffres peuvent être validés avec le filtre d'édition Special:AbuseFilter/17)
Robot and gadget jobsDevrait-il y avoir ou existe-t-il des bots ou des gadgets qui effectueront des tâches avec cette propriété? Par exemple: vérifier les autres propriétés afin d'être cohérent, collecter des données, automatiser un lien externe, etc.
Motivation

present in work (P1441) is sometimes used for characters, places, etc. that are barely named in a work but do not actually appear in it, for example the planet Coruscant (Q719329) is named several times in the original Star Wars trilogy, but no action takes place there and no image of the planet is shown. Ash Crow (talk) 16:50, 16 July 2015 (UTC)

Discussion
  •   Support. TomT0m (talk) 18:04, 16 July 2015 (UTC)
  •   Oppose. Things which are barely mentioned in a work should go in the statements about the work, not in the statements about the things. Recast this as "mentioned in this work". Filceolaire (talk) 04:18, 21 July 2015 (UTC)
  • +1   Oppose Please refine it. --Succu (talk) 21:06, 7 August 2015 (UTC)
  •   Oppose. Where is the separation line between "mentioning" and "full description"? 10 mentions are enough or not? --Infovarius (talk) 11:02, 9 August 2015 (UTC)
  • @Filceolaire, Succu, Infovarius: "Mentioned in this work" could be a reverse property but does not remove the need for this one. For example, if I make a list of the Amazons using the Wikidata List template on Wikipedia, I want to be able to show which ancien authors mentioned each of them... And one mention in a list should be enough. -Ash Crow (talk) 20:35, 23 August 2015 (UTC)
  •   Support Consider Abraham (Q9181). It would be useful (eg in queries) to be able to distinguish books of the Bible in which he was merely mentioned from books in which he was an active participant. Jheald (talk) 17:50, 14 September 2015 (UTC)
    • and you can do that by wikilinking mentions of him in the wikisource edition of the bible - much easier than trying to do something with wikidata properties. Joe Filceolaire (talk) 23:14, 14 September 2015 (UTC)

  Not done --Micru (talk) 14:08, 27 February 2016 (UTC)

production date / production year

   Not done
DescriptionDate (year) of production (broadcasting; might also be used for films)
Data typePoint in time
Template parameterProduktionsjahr (PJ) in de:Vorlage:Infobox Hörspiel
Domainaudio drama (Q2635894), radio documentary (Q2125867), ...
ExampleDu kannst mir viel erzählen (Q1262418) → 1949
Motivation

Basic info for broadcast productions (production company (P272) + year of production). The date a radio drama has been produced can be different from the (often unkown) date it has been first broacasted (original broadcaster (P449) + publication date (P577)). --Kolja21 (talk) 13:21, 10 September 2015 (UTC)

Discussion
Why not just use inception (P571) ? Jheald (talk) 17:26, 14 September 2015 (UTC)
inception (P571) is too broadly interpreted. It could be the start of production, or even the first time the work emerged as a concept. Josh Baumgartner (talk) 21:20, 14 September 2015 (UTC)
  Oppose Production covers a span of time (we do not currently have a data type for this). As I understand it, the 'production date' generally cited however is the completion of the production. If this is indeed the intent of this property, it should be re-labelled and described accordingly: date upon which production of a creative work is completed or some such. Additionally, the domain should be work (Q386724) as there are several subclasses of this that this could apply to as the completion of creation as distinct from the point of release/publication/broadcast. Josh Baumgartner (talk) 21:20, 14 September 2015 (UTC)
@Jheald: This property is used with dissolved, abolished or demolished date (P576) for en:Template:Infobox company: An organisation was founded and will be closed one day. (For a broadcast production that might or might not be the day the script has been finished ("written on date"), the day the production has been announced etc.) Imho we shoulded mix to many things in one property. --Kolja21 (talk) 21:27, 14 September 2015 (UTC)
@Kolja21: We use inception (P571) for all sorts of creative works -- paintings, novels, buildings, photographs. Why not films ? Jheald (talk) 21:25, 16 September 2015 (UTC)
@Josh Baumgartner: You can label it "year of production". We have this information for most of the archived broadcast productions and we need a property where we can store it. Example: de:Portal:Hörfunk/Wikidata lists/Hörspiele. (The date of production is one of the basic infos in every catalog.) --Kolja21 (talk) 21:38, 14 September 2015 (UTC)
  Support but the description should make clear that this refers to the year/date that production was completed, as noted in archives etc. Joe Filceolaire (talk) 11:58, 19 September 2015 (UTC)
  •   Oppose in preference to using significant event (P793) along with start and end dates, as is done with ships (building = production) for example: HMS Ark Royal (Q1333909). Also note that there are various phases which a film goes through, not just production, such as casting, filming, production, post-production, etc. Danrok (talk) 01:32, 18 December 2015 (UTC)
    •   Comment The date would just mention the date production was completed, not detail the various stages. I think it's important when no "date of publication" is available.
      --- Jura 15:09, 24 January 2016 (UTC)
  •   Oppose inception (P571) seems appropriate to me (in en has aliases like date of creation, creation date). --Jklamo (talk) 17:41, 2 January 2016 (UTC)
    • @Jklamo:: P571 would be when production started.
      --- Jura 15:09, 24 January 2016 (UTC)
  •   Support key date when date of publication isn't there.
    --- Jura 15:09, 24 January 2016 (UTC)
  •   Oppose significant event (P793) should be used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:35, 24 January 2016 (UTC)
    •   Comment Than we would need qualifiers, and things would getting so complicated that making a simple list of films or broadcast productions is impossible. We need this property for the same reason we need date of birth (P569). --Kolja21 (talk) 18:23, 10 February 2016 (UTC)

  Not done--Micru (talk) 14:10, 27 February 2016 (UTC)

Further reading (Book/article about subject)

   Not done
DescriptionMain literature about a person or a subject.
Data typeItem
Domainwork
Allowed valuesbooks and articles
ExampleOscar Wilde (Q30875) => Frank Harris: Oscar Wilde. His Life and Confessions. New York 1916.
Proposed byKolja21 (talk)
Discussion

We need a property for basic references that are not limited to a single information like "date of birth" etc. (See also Wikidata:Books task force.) --Kolja21 (talk) 19:09, 23 January 2014 (UTC)

Is it a "Biography-property" you are proposing? I would support that, but "Further reading" looks a little to unspecific. -- Lavallen (talk) 19:38, 23 January 2014 (UTC)
Imho we need this property for all subjects. (What would be the advantage of having a separate property only for persons = biographies?) Of cause the referred work should be "notable" in the meaning of presenting essential information about the item. --Kolja21 (talk) 20:41, 23 January 2014 (UTC)
How about "Book/article about subject" then? The problem with "Further reading" is that it may look like it invites to non-notable information or spam. I guess some projects have good guidelines about how the header "Further reading" should be used, but they are exceptions. -- Lavallen (talk) 11:59, 24 January 2014 (UTC)
"Book/article about subject" would be a good description. I've added it to the title. --Kolja21 (talk) 21:37, 24 January 2014 (UTC)
I would oppose this as the inverse of main subject (P921). --Izno (talk) 13:38, 24 January 2014 (UTC)
"Subject heading" is much broader. A book can have a dozen subject headings. "Further reading" (I try to use the same terminology as WP) should only contain the main works about an item. Take for example Boston University (section Further reading). It only contain 4 works but there can be hundreds of articles and books in WD with the subject heading "Boston University". --Kolja21 (talk) 21:48, 24 January 2014 (UTC)
  Comment Would statement is subject of (P805) work for the use case cited in the proposal? Emw (talk) 13:57, 24 January 2014 (UTC)
Good question. P805 is used in North Macedonia (Q221) and other items in a different way (not for literature). The German description "Datenobjekt über das Thema der Aussage" is hard to understand and needs further explanation. --Kolja21 (talk) 21:37, 24 January 2014 (UTC)
Let me understand: this would be a property for indicating the main works about a topic. It is thus different from the References or Bibliography on Wikipedia, right? Ths bothers me a bit, as, even so I understand the usefulness of such property, it would be very nnNOPV and it would not be decided in the Wikipedia page. I mean: the Wikipedia article is the place where there is the discussion and the creation of the article about the topic. They discuss and create the References section and the Bibliography section. Even that is extremely delicate, as you could really go nnPOV. But having a Further reading property just in Wikidata, disconnected by all the sections in Wikipedia, seems to much to me. Wikidata has a really small and dedicated community, we can't afford to decide by ourselves which is the "main" literature around a topic. If the Further reading was a conventional and common section in Wikipedia I would agree, but it seems to me it's not. --Aubrey (talk) 10:28, 26 January 2014 (UTC)
@Aubrey: We could add a note to WD:N or the talk page that only books or articles are allowed with this property that are used in the bibliography section of WP. This would minimize spam. --Kolja21 (talk) 05:54, 27 January 2014 (UTC)
On the other hand, Wikisource often have a "works about X" header in Author-namespace, so something like this is desired, no matter how Wikipedia is treating the matter. And then it does not matter how "main" the literature is or not. -- Lavallen (talk) 11:19, 26 January 2014 (UTC)
@Lavallen:, @Kolja21:: "works about X" is a good example, but it's kinda ambiguous. There are many books about X, sometimes, and not all of them should be staying in a "further reading" section. I generally like WD properties that are "facts", little pieces of information without POV issues. I agree that a simple metadata like "date of birth" or "nationality" is nnPOV sometimes, but they are often exceptions within a general rule. For example, in the Italian Wikisource we have 2 templates that are used when in a text an author/work is mentioned. See for example it:s:Storia_della_letteratura_italiana_(De_Sanctis)/I. I thus would like a "mentions" property for that, which could enumerate all the works and authors mentioned in a certain work. This is not "nnPOV", as it is the text which mentions them, and the community just puts manually the templates. This is the difference that makes me uncomfortable with the "Further reading" property proposal. Aubrey (talk) 10:19, 27 January 2014 (UTC)
I understand your worries, but intellectual work (looking at the content of a book) always involves the risk of POV issues. If you go to a library and ask for books about Oscar Wilde, you want an answer. If the librarian says: "I'm sorry, I have to be neutral but I can give you a a list of 50.000 books that mention this author", you can't work with this. --Kolja21 (talk) 15:41, 27 January 2014 (UTC)
In a first step stay with works which have an article in wikipedia or work used as reference in wikidata. This represents quite a large number of books. I think we have to fix some priorities. Snipre (talk) 13:04, 28 January 2014 (UTC)
This is understandable, but it remains unsatisfactory that, looking at the example Oscar Wilde (Q30875), an article of The Guardian (enWP, Citations 88) might be notable but main works about the author that are part of WP (listed under "References" and "Further reading") are ignored by WD. (See also: Book templates like de:Vorlage:BibISBN, used in 6 languages. Imho this bibliographic data should be transfered to WD.) --Kolja21 (talk) 14:49, 28 January 2014 (UTC)
  Support More books in Wikidata. --Recherchedienst (talk) 08:02, 3 April 2014 (UTC)

  On hold Lavallen, Kolja21, Izno, Emw, Aubrey, Snipre: since our aim is mostly to collect information about the world and support other Wikimedia projects, this property qualify for creation as long as it is wished and can be used by Wikipedias to store here their "further reading" preferences. However since WD isn't ready for technical reasons to deliver this info, I'm setting this proposal as "pending", to be created when Bugzilla: 47930 is finished.--Micru (talk) 16:55, 30 April 2014 (UTC)

Kolja21: Do we really need this? --Succu (talk) 20:05, 27 November 2015 (UTC)
Imho yes. "Further reading" (= bibliography) would be great for private or public lists about a person or a subject. (Example: en:Cèmuhî language#Bibliography.) statement is subject of (P805) is marked as "qualifier only". We use notable work (P800) although we have author (P50). "Further reading" would be the conterpart of main subject (P921) but it's not a 1:1 inverse property. - I left a note on Wikidata talk:WikiProject Books#Further reading. Hopefully this will bring more comments. --Kolja21 (talk) 21:25, 27 November 2015 (UTC)
Further reading, Kolja21? Something like de:George Engelmann/Schriften or de:Ernest Rutherford/Schriften? --Succu (talk) 21:43, 27 November 2015 (UTC)
No, for these lists we have notable work (P800) (deWP: Schriften / "Further reading" = Sekundärliteratur). --Kolja21 (talk) 22:00, 27 November 2015 (UTC)
  Question Is that valid? The documentation does not indicate that list items are acceptable values for notable work (P800). That sort of substitution strikes me as something that would complicate things. Dancter (talk) 22:30, 27 November 2015 (UTC)
Sure, Kolja21 … Both never published something… --Succu (talk) 22:37, 27 November 2015 (UTC)
This is a misunderstanding. notable work (P800) is not meant for list items: you can use this property for creating Wikidata lists. For a Wikimedia list of works use list of works (P1455). --Kolja21 (talk) 00:36, 28 November 2015 (UTC)
I think described by source (P1343) does this job. Joe Filceolaire (talk) 16:54, 22 December 2015 (UTC)
  Oppose We have described by source (P1343). Snipre (talk) 17:31, 21 January 2016 (UTC)

  Not done Use described by source (P1343).--Micru (talk) 14:13, 27 February 2016 (UTC)

culture

   Not done
DescriptionAncient site or object is associated with this human culture
Representsculture (Q11042)
Data typeItem
Template parameter"cultures" in en:template:infobox ancient site
Domainarchaeological/historic sites; archaeological finds
Allowed valuesany human cultures (Ancient Rome, Ancient Egypt, Inca Empire...)
ExampleColosseum (Q10285) → ancient Rome (Q1747689)
Motivation

The culture(s) associated with an ancient site or find is a basic bit of information for which there is no appropriate Wikidata property. This information is in the 'ancient site' wikipedia infobox, so is easy to import.

Discussion
  •   Support. We have time period (P2348) but before anyone suggests we use that, it does not represent the same thing. Thryduulf (talk: local | en.wp | en.wikt) 17:41, 2 January 2016 (UTC)
  •   Comment There is asimilar proposal at Wikidata:Property proposal/Generic#culture. – Máté (talk) 19:10, 31 January 2016 (UTC)
    • Yes, I moved my proposal to the Generic page (I initially changed it to be 'associated people' instead, but have now reverted to 'culture'.
  • Marking as   Not done because the proposal has been moved. Mbch331 (talk) 19:34, 28 February 2016 (UTC)


Front matter

   Withdrawn
DescriptionAuthor of front matter (including forewords, introductions, prefaces, etc.) of a book or other work
Data typeItem
Domainwritten works
Allowed valuespeople
ExamplePhantoms in the Brain (Q2149841) → Oliver Sacks (Q258662) (with qualifier applies to part (P518) = foreword (Q1358138))
Motivation

Missing property. Swpb (talk) 19:03, 26 February 2016 (UTC)

Discussion
  Comment. This is already proposed higher up on this very page. Vote for there. Thierry Caro (talk) 10:49, 27 February 2016 (UTC)
Ah, thanks. I am withdrawing here. Swpb (talk) 15:00, 29 February 2016 (UTC)

Bach-Werke-Verzeichnis number

   Not done
Descriptionnumber of a work by Johann Sebastian Bach in the Bach-Werke-Verzeichnis
RepresentsBach-Werke-Verzeichnis (Q214203)
Data typeString
Allowed valuesnumbers between 1 and ca. 1100, optional suffixes like a, b, c... (Anh. or deest would be expressed by qualifiers)
ExampleDer Geist hilft unser Schwachheit auf, BWV 226 (Q1193795) → 226
Sourcew:de:Bach-Werke-Verzeichnis
Begründung

The Bach-Werke-Verzeichnis is the most important catalog for Bach's works. It is updated continuously and provides a strong identifier for Bach's works. Lists could be created based on this information, e.g. for Wikipedia. T.seppelt (talk) 17:49, 3 May 2015 (UTC)

Discussion
  Comment last discussion: Wikidata:Property_proposal/Archive/20#Bach-Werke-Verzeichnis --Pasleim (talk) 20:50, 4 May 2015 (UTC)

@T.seppelt: Please specify the single formatter URL which we should use.

  Not done Use catalog code (P528) with qualifier catalog (P972)=>Bach-Werke-Verzeichnis (Q214203) instead. @T.seppelt: If you want to link with bach-digital.de, then propose a property for that website.--Micru (talk) 13:19, 4 March 2016 (UTC)

BabelNet id

   Done: BabelNet ID (P2581) (Talk and documentation)
Description...
RepresentsBabelNet (Q4837690)
Data typeExternal identifier
Domainany item
Example
Sourcehttp://babelnet.org
Formatter URLhttp://babelnet.org/rdf/s$1 for RDF (data access), http://babelnet.org/synset?word=bn:$1 for web (better eg for Mix-n-Match display)
Robot and gadget jobssome data: https://www.wikidata.org/wiki/Wikidata:WikiProject_Authority_control#DBpedia-Wordnet3_coref
Motivation

BabelNet is a very important linguistic & encyclopedic resource. It integrates multilingual Wikipedia, Wordnets and many other sources (eg OmegaWiki).

It enables all kinds of multilingual semantic research. For example, at https://www.wikidata.org/wiki/Wikidata:WikiProject_Authority_control#DBpedia-Wordnet3_coref we will use it to coreference part of AAT Vladimir Alexiev (talk) 11:56, 29 May 2015 (UTC)

Discussion

  Support. This raises an interesting question. How many other authority control sites have an RDF url as well as the url for human readable version? Do we need a formatter url for RDF download property? Joe Filceolaire (talk) 17:30, 21 August 2015 (UTC)

  Done @Vladimir Alexiev, Nono314: --Micru (talk) 13:39, 4 March 2016 (UTC)

ID for entity pages at Deutsche Digitale Bibliothek

   Not done
DescriptionThe Deutsche Digitale Bibliothek is the central German national portal for culture and science. It is providing entity pages, based on the GND authority file. At the moment pages which are providing information about persons are implemented, e.g. Johann Wolfgang von Goethe. Other entity types, like places and corporate identities will follow soon. The identifier of DDB is equal to the GND ID (P227), but not all GND entities do have an entity pages at DDB portal.
RepresentsIntegrated Authority File (Q36578)
Data typeExternal identifier
DomainAny entities types of GND Authority File
Allowed values
(1|10)\d{7}[0-9X]|[47]\d{6}-\d|[1-9]\d{0,7}-[0-9X]|3\d{7}[0-9X]
ExampleJohann Wolfgang von Goethe (Q5879) → 118540238
SourceExternal Reference
Formatter URLhttps://www.deutsche-digitale-bibliothek.de/entity/$1
Robot and gadget jobsCould be added by a bot, based on BEACON files
Motivation

I am working for Deutsche Digitale Bibliothek and we are strongly interested in a cooperations with Wikidata community. Adding this property to Wikidata could help to improve Wikipedia article and enable the import of free DDB objects to the Wikipedia universe. Michael Büchner (talk) 13:35, 17 September 2015 (UTC)

Discussion
  •   Support. Joe Filceolaire (talk) 11:38, 18 September 2015 (UTC)
  •   Comment it seems this is redundant to existing GND ID (P227). --- Jura 11:42, 18 September 2015 (UTC)
    •   Oppose I guess then it is. --- Jura 09:06, 1 October 2015 (UTC)
    •   Comment It is redundant. Do you have any suggestion how to realize it a better way? Actually we only need a boolean information and if it's TRUE than we could use the ID of Property:P227. --Michael Büchner (talk) 08:27, 2 October 2015 (UTC)
      •   Comment Well, Wikidata might record several GND identifiers for the same entity: How would we know what the correct one(s) would be for referring to DDB? Or the other way round: The GND might have merged several GND records into one, how quickly would the DDB perform the corresponding adjustments for that "redirection"? So a string valued datatype plus some clever constraints checking ("value usually follows P227" - this would have to be implemented accordingly - seems adequate for me. -- Gymel (talk) 15:37, 2 October 2015 (UTC)
        •   Comment Entity Pages of the DDB are based on Entity Facts. To support merged GND records we implemented a HTTP redirection for secondary IDs to the primary ID, e.g. 10142051X -> 116276932. This data service is always up-to-date! In a couple of weeks DDB's entity pages will behave in the same way, so is doesn't matter which ID you'll provide. --Michael Büchner (talk) 09:32, 5 October 2015 (UTC)
      •   Comment If you need QIDs for GNDs, you can use beacon. --- Jura 09:17, 4 October 2015 (UTC)
  •   Comment I'd be happy if we could continue to work on a possible solution! I'm still sure that the DDB's entity page could be a helpful enrichment for Wikidata. What do you think, are there other supporters? --Michael Büchner (talk) 16:39, 20 January 2016 (UTC)
  •   Oppose GND numbers are used in a vast number of projects. Instead of creating Wikidata properties for each of them see w:de:Wikipedia:BEACON for an alternative. -- JakobVoss (talk) 08:52, 11 February 2016 (UTC)
    •   Comment DDB is already providing a BEACON file. Storing the information if there is a DDB entity page at Wikidata was a proposal of the Wikipedia community itself. See here for example. Another information we can provide is the number of object we have for every entity. That might be helpful if someone would like to have a ranking of different entity pages (like the links at Personensuche) --Michael Büchner (talk) 12:52, 15 February 2016 (UTC)

  Not done Per comments.--Micru (talk) 13:46, 4 March 2016 (UTC)

Barnivore ID

   Not done
DescriptionProperty for alcoholic beverages and whether they are vegan or not
Data typeExternal identifier
Domainalcohol brands
Allowed values0-9, a-z
ExampleAbsolut Vodka (Q332378) → 5574-absolut-vodka
Sourcehttps://en.wikipedia.org/wiki/Category:Vegetarianism_and_drinks
Formatter URLhttp://www.barnivore.com/products/$1
Motivation

It has a clear, unique and defined ID for every brand. Should be useful for automating whether it is vegan or not, with some more comments on it. Pikolas (talk) 11:39, 21 October 2015 (UTC)

Discussion
  • Comment I've no view as to whether or not we should have this property, but I do not think we should use these identifiers for "automating whether [an item] is vegan or not"; we should have a property for that, or indicate the contrary it by showing the relevant ingredients. In any case, this status is liable to change. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:27, 24 October 2015 (UTC)
  • Comment Would be useful for Open Food Facts (which is being linked to Wikidata)Teolemon (talk) 21:50, 11 December 2015 (UTC)

  Not done Lack of support.--Micru (talk) 13:48, 4 March 2016 (UTC)

New York Times Semantic Concept

   Withdrawn
DescriptionThe New York Times associates Semantic Concepts, representing people, places, organizations and descriptors, with articles. These concepts are exposed both through metadata embedded in the HTML of articles as well as through its Semantic API. In some cases, the internal New York Times Semantic Concepts are related to the linked data cloud through an interface provided at [ http://data.nytimes.com/ data.nytimes.com ] and/or the Semantic API.
Data typeString
Template parameternone
Domainpeople, organizations, places, descriptors
Allowed valuesstring with a mandatory qualifier which is one of "nytd_geo", "nytd_per", "nytd_org", "nytd_des"
ExampleBarack Obama (Q76) → "Obama, Barack" with a qualifier of "nytd_per"
Format and edit filter validationqualifier must be one of "nytd_geo", "nytd_per", "nytd_org", "nytd_des"
Sourceexternal reference, Wikipedia list article, etc.
Robot and gadget jobsMany concepts are already related to Wikipedia items by the New York Times Semantic API, a bot could automatically import this data.
Motivation

Being able to associate New York Times articles with semantic concepts opens up an avenue for many third party applications to interact with their data. The Times has already associated a subset of their controlled vocabulary with Wikipedia items, so part of the work is already done. Thinkcontext (talk) 22:40, 20 November 2015 (UTC)

Discussion
  •   Question. Do we have a way of automatically choosing a formatter URL based on the nytd_ qualifier? Runner1928 (talk) 05:39, 21 November 2015 (UTC)
  •   Question Thinkcontext I don't understand the part of the qualifiers. "nytd_geo", "nytd_per", "nytd_org", "nytd_des" are the qualifier property or the value? If they are qualifier properties what should be the value in the example? If they are qualifier values which qualifier property should be used? -- Agabi10 (talk) 21:25, 21 November 2015 (UTC)
  • Agabi10 I admit, I am a little confused about how best to express the NYTimes Semantic Concept as a property. Thryduulf makes a good suggestion, but I am a bit of a newb here and could use some advice. Thinkcontext (talk) 16:25, 24 November 2015 (UTC)
  •   Question would not four properties, one for each of the concept types, be better? Thryduulf (talk: local | en.wp | en.wikt) 22:15, 21 November 2015 (UTC)
  • Comment: The NYT website cited gives http://data.nytimes.com/47452218948077706853 as the URL for its record for Barrack Obama. We would do better to store the value "47452218948077706853" (as a string) with the formatter URL "http://data.nytimes.com/$1". The qualifier is available as A URL ("http://data.nytimes.com/elements/nytd_per") from the former URL, and so need not be stored by us. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:56, 22 November 2015 (UTC)
  • Andy Mabbett There are a couple issue with this. data.nytimes.com is incomplete, and, as far as I can tell, unmaintained for some years. Second, the identifier it uses is not exposed in the article metadata unlike their Semantic Concept. I think its important to be able to use an identifier exposed in the html of the article, this would enable browser extensions to, say, notify the user of political donations by the entities discussed in the article. I don't object to having a separate property for the data.nytimes identifier, but I think there is value for having one for the Semantic Concept. Thinkcontext (talk) 16:18, 24 November 2015 (UTC)
  Support Andy's suggestion. Runner1928 (talk) 19:09, 23 November 2015 (UTC)
  • Thryduulf It doesn't sound like anyone likes my original idea, though perhaps I didn't express it well. The alternate proposal to use the data.nytimes id, I think has problems, as I commented.  – The preceding unsigned comment was added by thinkcontext (talk • contribs).
    • I think the idea has merit, but your suggested implementation could be improved upon. I was hoping to spur some more comment here to see if proposing three properties as I suggested above would get any interest. I agree with you about data.nytimes, and don't support that suggestion. Thryduulf (talk: local | en.wp | en.wikt) 20:05, 31 January 2016 (UTC)
      • Thanks for the effort to move this forward. I'm fine with your suggestion of multiple properties if that would bring others on board. The NYTimes has done the hard work of associating these concepts with the Linked Data Cloud, I think it would be an easy way for Wikidata to add value by supporting it. Thinkcontext (talk) 21:56, 1 February 2016 (UTC)
        • I suggest five properties: four for concept names where concept types are known (type String for properties nytd_geo for locations, nytd_per for people, nytd_org for organizations, and nytd_des for descriptors), as well as type Number concept_uri for numeric URIs. Wikidata entities should have at most one of the concept names, and can also have a concept_uri. Since the Times has already done the work of associating nytd_geo/Kansas with Kansas (Q1558) via sameAs: http://en.wikipedia.org/wiki/Kansas, we can bot-import that data. Five properties also works well since there are five specific formatter/query URLs. Runner1928 (talk) 22:13, 1 February 2016 (UTC)
  • I marked this proposal as withdrawn given the new proposals listed below from Thinkcontext to replace this one. ArthurPSmith (talk) 14:23, 3 March 2016 (UTC)

J. Paul Getty Museum object id

Descriptionidentifier assigned to a work of art by the J. Paul Getty Museum
Data typeExternal identifier
Domainworks of art
Allowed values\d+
ExampleRembrandt Laughing (Q20178648) → 263156
Sourcehttp://www.getty.edu/art/collection/
Formatter URLhttp://www.getty.edu/art/collection/objects/$1
Robot and gadget jobsAdd to Mix'n'Match ??
Motivation

Decent amount of info about the artwork. Images (even Deep Zoom) available under a very liberal open content license: "to be used for any purpose. No permission is required". To complement the previous proposal. --Vladimir Alexiev (talk) 12:36, 29 December 2015 (UTC)

Discussion

I'm not sure a new property would add a lot. All items are already linked using described at URL (P973). Multichill (talk) 10:30, 9 January 2016 (UTC)

  •   Support - I also thought, we need this property. There will come the entries (I'm working on it!) and described at URL (P973) will not help. We definetly need this, and too for the MET, British Museum, Arachne, SMP Berlin, MfA Boston and so on. There WILL come thousands, tenthousands, maybe hundredthousands of entries. Marcus Cyron (talk) 11:14, 18 February 2016 (UTC)

  Done @Vladimir Alexiev, Multichill, Marcus Cyron: --Micru (talk) 13:53, 4 March 2016 (UTC)

Regions of France

   Not done
Descriptionfor administrative regions of France
Data typeItem
Template parameter|subdivision_name1= in en:Template:Infobox settlement
ExampleSaône-et-Loire (Q12736) => Bourgogne-Franche-Comté (Q18578267)
Robot and gadget jobsSee motivation
Motivation

Was trying to get used to working with wiki tools. So started looking for bot requests to fill. I have been working on en:Wikipedia:Bot requests#New French regions on 1 January. At first I was trying to do it just using pure text replaces. But this is not ideal because the program would need rerun if the data was needed again. Would be better to just use the property value for the page. Using wikidata was suggested here by User:RexxS Thanks for any help you can give me. Looking at the preview it looks like I am messing up the syntax for the request some how. Still going to post Lonjers (talk) 21:11, 6 January 2016 (UTC)

Discussion

  Not done Lack of support.--Micru (talk) 13:58, 4 March 2016 (UTC)

version

   Not done
DescriptionVersion of a work such as records, plays, books
Data typestring, number-invalid datatype (not in Module:i18n/datatype)
Domainreferences
ExampleTumor protein p53 (Q283350) UniProt protein ID (P352) "04637" → "237"
Sourceexternal reference
Motivation

I specifically need this property to capture the provenance on Protein items in Wikidata. Content is retrieved from Uniprot. Records in Uniprot are constantly being updated and with each new update a protein record gets a new version number. Currently, the version is stored using the property reference URL (P854) e.g. http://www.uniprot.org/uniprot/P04637.txt?version=237. We would like to be able to store a version of a source as a proper value, not being part of a URL. Although this example is highly domain specific, I believe a version to be applicable on other domains as well. I first thought edition to be a prime candidate to capture the sequence of a release, however, on second thoughts a version applies an updated item on the same concept, whereas edition suggests the same context but could differ on the context (e.g. A next edition of a newspaper, doesn't report an update on news reported in the previous edition Andrawaag (talk) 23:37, 8 January 2016 (UTC)

Discussion
  Comment Hmm. edition number (P393) might give the meaning you want. Or series ordinal (P1545). Runner1928 (talk) 01:49, 9 January 2016 (UTC)

  Not done Redundant.--Micru (talk) 14:00, 4 March 2016 (UTC)

Baltisches Biographisches Lexikon digital ID

RepresentsBaltisches biografisches Lexikon digital (Q18616550)
Data typeExternal identifier
Domainhuman (Q5)
ExampleFelix Eduard Wreden (Q15065137) → Wreden-Felix-Eduard-1841-1878
Sourcehttp://www.bbl-digital.de/
Formatter URLhttp://www.bbl-digital.de/eintrag/$1/
Robot and gadget jobsMy bot can import values from Wikipedias
Motivation

Useful for Baltic Germans. Source used in several Wikipedias. Edgars2007 (talk) 21:17, 22 January 2016 (UTC)

Discussion
  •   Support - definetly yes. Marcus Cyron (talk) 11:16, 18 February 2016 (UTC)
  •   Support -- Gymel (talk) 07:03, 24 February 2016 (UTC)

  Done @Edgars2007, Marcus Cyron, Gymel:--Micru (talk) 13:14, 4 March 2016 (UTC)

has phoneme

   Done: has phoneme (P2587) (Talk and documentation)
Descriptionthe language's phonology includes this sound
Data typeItem
Domainlanguage (Q34770)
Allowed valuesphoneme (Q8183) phone (Q202064)
ExampleEnglish (Q1860) → voiced bilabial nasal (Q201817), voiceless dental fricative (Q332019), voiceless velar plosive (Q463543), ... (22 others)
Robot and gadget jobsThis data could concievably be imported from various WP articles or various online databases.
Motivation

Sounds not used in all dialects could be marked with applies to part (P518). I'm not sure what property to suggest for marking Allophony, it may require its own property (e.g. "Allophone of"). Popcorndude (talk) 22:00, 12 August 2015 (UTC)

Discussion

It may be interesting having that property, but how would we handle different phonological analysis? Moreover, Wikipedia does not have articles about phonemes, but articles about phones. I'm a bit skeptical about this property, but we should discuss it. --SynConlanger (talk) 19:59, 17 August 2015 (UTC)

I only recently learned the precise distinction between phones and phonemes, so it is quite possible that the above wording should be changed.
I had not previously encountered differring phonological analysis. I shall have to think on this. Popcorndude (talk) 20:36, 17 August 2015 (UTC)
statement disputed by (P1310)? Popcorndude (talk) 20:37, 17 August 2015 (UTC)
Mmmh, not sure. It may be one phoneme only that is disputed, or more than one, and different sources may dispute a different set. It can get quite complex. We could however rely on an arbitrary external phonological database and stick to that, like Phoible. Yeah, I think choosing one database should work. What do you think? Again, the problem remains that wikipedia does not have articles for phonemes and the same phoneme label could actually match different phonetic labels, so it wouldn't be safe, we need a proper work around I cannot think of... --SynConlanger (talk) 20:56, 17 August 2015 (UTC)
Oh yeah, also, there won't be a page for some phonemes because they are modifications of phones which are very unlike to be listed as items here or pages in Wikipedia. Like long vowels for example. I think we should concentrate first on standard phones, and then maybe move to phonemes. --SynConlanger (talk) 21:01, 17 August 2015 (UTC)
Perhaps this could be another use case of the "secondary articulation" discussed at Wikidata_talk:WikiProject_Linguistics#property_idea
e.g. "Language X":
  • "phonology contains" => "voiced dental fricative":
I have also corrected the above to phone and made consonant and vowel subclasses of phone rather than phoneme. Popcorndude (talk) 21:36, 17 August 2015 (UTC)
What if the language has two vowels that differ only in length? We would insert twice the same item as a value of this property and we would add a qualifier to the two values ("short" and "long" respectively)? --SynConlanger (talk) 21:59, 17 August 2015 (UTC)
I would say yes. Popcorndude (talk) 22:51, 17 August 2015 (UTC)
SynConlanger, Popcorndude I would say no. Instead have two item - a long version and a short version of the vowel - treat them as different phones/phonemes. Joe Filceolaire (talk) 10:22, 11 November 2015 (UTC)
  •   Support I'm not familiar with the linguistics but I can see that this property would allow us to make useful statements about languages and maybe about accented versions of those languages (in many cases we have separate items for these). Joe Filceolaire (talk) 23:52, 20 August 2015 (UTC)
We don't have separate items for IPA symbols with diacritics, I'm afraid you're mixing "letters" and "sounds" here. --SynConlanger (talk) 14:01, 21 August 2015 (UTC)
  •   Neutral I'm not against this property in principle, I'm just concerned about its practical application, as noted above. But we could try it out. --SynConlanger (talk) 14:01, 21 August 2015 (UTC)
  •   Question Would uses (P2283) and used by (P1535) be sufficient to do this:
These would seem to fit the bill, am I missing something? Josh Baumgartner (talk) 23:15, 6 November 2015 (UTC)
I would be willing to use that instead. (Although using used by (P1535) may not be advisable, given the number of languages) Popcorndude (talk) 00:48, 7 November 2015 (UTC)
They would sort of fit the bill but I believe for specialised concepts and domains like this it is justified to have specialist properties instead of using these general properties. Joe Filceolaire (talk) 10:22, 11 November 2015 (UTC)
  • But these statements will require qualifiers. Because language may use also specific tenses, specific cases, specific aspects and so on. --Infovarius (talk) 16:35, 4 December 2015 (UTC)
    Those are aspects of morphology, which would be dealt with using other properties. Popcorndude (talk) 16:41, 4 December 2015 (UTC)
  •   Support but I don't think applies to is useful if we have items for the dialects. Just put the statements in the dialect item. author  TomT0m / talk page 20:54, 24 January 2016 (UTC)

DNB

   Withdrawn
Descriptionentry in the Dictionary of National Biography
Data typeItem
Domainpeople primarily
Allowed valuesitems for DNB entries at Wikisource
ExampleEdward of Norwich, 2nd Duke of York (Q452639) → ‘Plantagenet,’ Edward (Q19019224)
Sourceitems with described by source (P1343) and such entries
Robot and gadget jobsKrBot for constraint checks
  •   Support The current solution with described by source (P1343) (outcome of a previous proposal) doesn't allow efficient constraint checks. P1343 being used on a mix of items. Obviously, it could be a "subproperty" of P1343. --- Jura 09:31, 4 November 2015 (UTC)
    What kind of constraint checks is needed? -- Sergey kudryavtsev (talk) 04:08, 5 November 2015 (UTC)
  •   Support Good idea to do it this way. Jonathan Groß (talk) 09:41, 4 November 2015 (UTC)
  •   Support seems reasonable enough. Andrew Gray (talk) 12:30, 4 November 2015 (UTC)
also, @Charles Matthews: Andrew Gray (talk) 12:30, 4 November 2015 (UTC)
  • Comment. This limits DNB entries to the first edition and first two supplements. i.e. those currently in the US public domain and so on Wikisource. There are nearly ten further DNB volumes (decade supplements, plus one volume for people who were afterthoughts), before the ODNB arrived in 2004 with actual identifiers. Therefore this property is somewhat artificial from a bibliographical point of view. In other words, one can imagine cases where described by source (P1343) would still have to be used for the DNB. I don't object, but the proposal has to be seen as ad hoc. Charles Matthews (talk) 13:39, 4 November 2015 (UTC)
  •   Oppose All encyclopedias should be handle same way. I prefer the solution with described by source (P1343), which allow to add new encyclopedia without a request a new property. -- Sergey kudryavtsev (talk) 04:08, 5 November 2015 (UTC)
  •   Oppose per discussions Wikidata:Property proposal/Archive/31#DNB entry at Wikisource and Wikidata:Property proposal/Archive/31#Catholic Encyclopedia entry at Wikisource --Pasleim (talk) 09:22, 11 November 2015 (UTC)
    • @Pasleim:: in 6 months, such a templateproperty hasn't seen the day and, independently of the others, I think the mere size of DNB warrants the ease offered by specific property. --- Jura 00:42, 15 November 2015 (UTC)
  •   Oppose as per Pasleim--Kopiersperre (talk) 13:02, 14 November 2015 (UTC)
  •   Comment I am quite comfortable with the "described by" approach as something like enWP can pull a count and information about references. The issue I see at the moment is that the property has been used in two ways.
    1. to the overarching work where it is a non-specific reference, ie. such a work contains an article (and no more detail), though detail of vol. and page, or article could be given and is often used in the reverse way with "published in …"
    2. to the article (as has been done with DNB articles)
So it is a bit of a mess. The means to resolve that is to work out which it is to be, or if both are acceptable then how they are differentiated. To me it makes sense to have a qualifier to describe the parent work of the article. We also need to consider how this can work, such as at the WSes, which have the articles and need to run quick/simple data pulls to the their wiki, not wanting to run high-powered queries.

So maybe it is needs a fuller exploration of what is looking to be achieved and whether we have the components in place rather than some of the simpler "I don't like it" responses.  — billinghurst sDrewth 03:12, 15 November 2015 (UTC)

The combination of described by source (P1343) with section, verse, paragraph, or clause (P958) can be used as a statement with qualifier and also within a reference claim. Specifying the overarching work (recte: specific edition of that work?) has huge merits as previous discussions emphasized, it`'s that work which allows accessing the quality of the reference. Infering this from information contained in a target item might be currently beyond the capabilities of most data consumers. However when we have specific items for entries in reference works they usually have additional statements which must be accessible, too. A minimal approach could consist of introducing a qualifier only property "reference item" to be used together with described by source (P1343) (in both situations). One probably will not be able to prohibit use of this item in contexts without overarching work of "dictionary" type, but IMHO use for journal articles or even individual blog entries seems to be appropriate. -- Gymel (talk) 11:44, 15 November 2015 (UTC)
You can specify this on the property definition page. Just as we do for most other online works. No need to repeat it on every P31:Q5. --- Jura 11:56, 15 November 2015 (UTC)
@billinghurst: This situation is appear due to Wikidata:WikiProject DNB#Examples : Subject of DNB entry recomends an improper use of P1343. I consider that this should be coverted to use with stated in (P248) as qualifiers. I can run my bot to fix it. -- Sergey kudryavtsev (talk) 08:31, 17 November 2015 (UTC)
@Sergey kudryavtsev, Gymel, Jura1: I am not sure what any of you are arguing in your later comments. I would suggest that would be resolved by examples of what would be right, and what is wrong. For P1343 which is right and which is wrong?  — billinghurst sDrewth 09:21, 17 November 2015 (UTC)
Supposedly the current use for P1343 is the outcome of a lengthy debate, thus I don't see a point of doing that change.
It's a non-issue if we use a separate property for DNB. --- Jura 09:32, 17 November 2015 (UTC)
I'm not principally opposing a dedicated property, but my proposal would be:
So P1343 gives only a gist from what's recorded in more detail in Q19019224 (questionable use of chapter (P792) there IMHO) and emphasizes the broader publishing context of the source. This is still a bit more indirect than in other cases without Wikidsource edition, where we appreciate a direct web link to the article via an additional qualifier . -- Gymel (talk) 10:36, 17 November 2015 (UTC)
@billinghurst: For P1343 which is right and which is wrong? — Usage rules of P1343 described in Property talk:P1343, of course. DNB is stored at enwikisource, so it should follow the second example in Property talk:P1343. I consider that the property usage rules have a highest priority over any project rules. Jura1 told some kind of "debates". But the property usage rules has scope whole Wikidata. There isn't even any notification at Property talk:P1343 about this consensus.
The motivation to use a qualfier. In the fact stated in (P248) as qualfier optimizes a retrieving information for a computer programs. If article item be a value of P1343, then a program code is obliged to inspect a claims in all item stored as P1343 values. But if a article item stored as a qualfier value for known values (such as Dictionary of National Biography, 1885–1900 (Q15987216), Brockhaus and Efron Encyclopedic Dictionary (Q602358) etc), then a program code may search only claims of P1343 with values needed to its purpose.
The logic P1343 with stated in (P248) and reference URL (P854) as qualfiers is already programmed in LUA-modules at least in ruwiki and ruwikisource. -- Sergey kudryavtsev (talk) 11:21, 17 November 2015 (UTC)
It doesn't currently work for DNB in ruwiki (with any approach), but a fix is available if a new property would be created. --- Jura 14:12, 18 November 2015 (UTC)

  Comment Now ruwiki shows DNB article links from wikidata (e.g. w:ru:Мур, Эдвард, w:ru:Льюис Кэрролл and w:ru:Мередит, Джордж, see at the end of page). putnik do this on my request. -- Sergey kudryavtsev (talk) 14:38, 5 February 2016 (UTC)


Baseball-Reference.com ID

   Not done
Descriptionidentifier for a Major League Baseball player assigned by Baseball-Reference.com
Data typeExternal identifier
Template parameterWikidata property related to sport (Q21818626)
ExampleMike Trout (Q3090378) → 545361
SourceMLB.com
Formatter URLhttp://m.mlb.com/player/$1
Robot and gadget jobsNone
Motivation

I would like to add this for each player as an identifier for a Major League Baseball player  – The preceding unsigned comment was added by Mattdorville (talk • contribs) at 19:48, 2 March 2016‎ (UTC).

Discussion

@Mattdorville:   Not done. Baseball-Reference.com major league player ID (P1825) already exists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:53, 3 March 2016 (UTC)

founder of (alias: founded)

   Withdrawn
Descriptionentity that the subject of this item founded
Data typeItem
Domainhuman (Q5), organization (Q43229)
Allowed valuesorganization (Q43229), geographical feature (Q618123), architectural structure (Q811979), website (Q35127)
ExampleFatima al-Fihri (Q182363) → University of al-Qarawiyyin (Q378014), Ray Hyman (Q432812) → Committee for Skeptical Inquiry (Q1115728), Huguette Marcelle Clark (Q514218) → Andree Clark Bird Refuge (Q4755706)
Robot and gadget jobsreplace incorrect uses of founded by (P112) with this property
Motivation

This is the inverse of founded by (P112) but I've discovered that there are lots of incorrect uses of that property to do exactly this job. I found the first example while looking to improve Fatima al-Fihri (Q182363) and the other two examples were from a very quick look at Wikidata:Database reports/Constraint violations/P112 (see also Property talk:P112 for comments about other constraint violations). Thryduulf (talk: local | en.wp | en.wikt) 11:15, 7 March 2016 (UTC)

Discussion
  Withdrawn I've just spotted #founder of has already been proposed elsewhere on this page so I'm withdrawing this proposal as a duplicate. Thryduulf (talk: local | en.wp | en.wikt) 11:35, 7 March 2016 (UTC)


Geni.com Profile ID

DescriptionIdentifier for a profile on the Geni.com genealogy website
Representsgeni.com (Q2621214)
Data typeExternal identifier
Domainhuman (Q5)
Allowed valuesstring pattern containing [A-Z][a-z][0-9][-][/]
ExampleElizabeth II (Q9682) → Queen-Elizabeth-II-of-the-United-Kingdom/6000000003075071669
Format and edit filter validationThe string contains one [/]. All characters before the [/] are [A-Z][a-z][0-9][-], and all characters after the string are [0-9]. No limit on length.
SourceGeni.com website
Formatter URLhttp://www.geni.com/people/$1
Robot and gadget jobsNot required, but Geni does have an API which can be used to cross-check data such as birth date, etc if anyone with the required skills is interested.
Motivation

Geni.com is a genealogy website with over 100 million profiles - all connected, including a large number of notable people (who would have Wikipedia/Wikidata entries). The website can calculate relationships between any two people on the tree (examples: 1 2 3 4), although this is limited to paid members so may not be directly useful to Wikidata at this point in time. For sample profile URLs, check the current trending names on Geni. Disclosure, I am a paid member of Geni, but have no other affiliation.

This is my first proposal for a new property, please be gentle! -- Chuq (talk) 11:57, 22 February 2016 (UTC)

Discussion
  •   Support It is also on my list to suggest. It has a good landing page and you can add documents and images. If you can link yourself back 5 generations in Europe into the forest (the name for merged genealogy trees) you can see how your are related to just about anyone of European ancestry. As duplicate records get merged Geni keeps a redirect. --Richard Arthur Norton (1958- ) (talk) 23:32, 22 February 2016 (UTC)
  • Datatype changed to "External identifier". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 3 March 2016 (UTC)
  •   Support Very useful. --Edgars2007 (talk) 20:57, 8 March 2016 (UTC)

  Done @Chuq, Richard Arthur Norton (1958- ), Pigsonthewing, Edgars2007:--Micru (talk) 21:42, 8 March 2016 (UTC)


superhuman feature or ability

Descriptionsuperhuman, supernatural, or paranormal abilities that the subject exhibits
Representscapability (Q1347367)
Data typeItem
Template parameter"powers" in en:template:Infobox comics character and title
Allowed valuesAbilities listed at en:List of superhuman features and abilities in fiction, though not limited to the list
ExampleScarlet Witch (Q929285) → reality warping (Q21451555)
SourceList of superhuman features and abilities in fiction
Motivation

Would be nice for items about super-characters. You can move this proposal if it's in the wrong place. --AmaryllisGardener talk 01:41, 11 November 2015 (UTC)

Discussion
  •   Support. Joe Filceolaire (talk) 10:44, 11 November 2015 (UTC)
  •   Support Mbch331 (talk) 21:34, 11 November 2015 (UTC)
  •   Support as a broader 'ability' property. I see no reason to limit it to superheroes and their powers, but instead any notable abilities of an entity ought to be able to use this property. Josh Baumgartner (talk) 21:23, 13 November 2015 (UTC)
    Like reading (Q199657)? Jonathan Groß (talk) 21:54, 13 November 2015 (UTC)
If it is notable that an item is capable of reading (Q199657) then I would think so. Josh Baumgartner (talk) 22:53, 13 November 2015 (UTC)
Yeah, but how would we determine if something is notable or not? Someone could add "ability > reading", "ability > speaking", "ability > walking" and so on to all person items ... what would we do about it? Revert those edits? Jonathan Groß (talk) 12:33, 17 November 2015 (UTC)
Fictional characters only, That's how you solve that problem. Also, perhaps make an item called something like "superhuman ability", then set up a constraint, and there you go. --AmaryllisGardener talk 19:33, 24 November 2015 (UTC)
You do not see such kind of information in regular Wikipedia articles. I see no reason to worry that Wikidata would be any differnt. That means the notability test can be exactly the same as for Wikipedia. --Flukas (talk) 16:09, 23 February 2016 (UTC)
  •   Oppose Fancruft--Kopiersperre (talk) 13:02, 14 November 2015 (UTC)
  •   Support, but only in the narrow confines of superheroes; re-labelled as "superpower" or suchlike. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:06, 19 November 2015 (UTC)
  • It should be restricted to fictional entities regardless. I think I also agree with Kopiersperre. --Izno (talk) 15:54, 7 January 2016 (UTC)
  •   Support even in the broader sense. --Flukas (talk) 22:09, 22 February 2016 (UTC)
  •   Support Thierry Caro (talk) 11:05, 27 February 2016 (UTC)

  Done @AmaryllisGardener, Joshbaumgartner, Jonathan Groß, Flukas, Kopiersperre, Thierry Caro:@Mbch331, Pigsonthewing, Izno:--Micru (talk) 18:09, 27 February 2016 (UTC)

National-Football-Teams.com player id

   Withdrawn
Descriptionplayer id at National-Football-Teams.com
Data typeExternal identifier
Template parameterpid in en:template:NFT_player
Domainhuman
Allowed valuesnumerical value
ExampleDavid Beckham (Q10520) → 2189
Sourcethe website or wikipedia templates
Formatter URLhttp://www.national-football-teams.com/player/$1.html
Robot and gadget jobsbots could be created to import from templates
Motivation

National Football Teams (http://www.national-football-teams.com/) seems to be a useful resource for information about domestic and international football (soccer). There are templates that use the website on various language wikipedias, and at least the english template is widely used (18263 transclusions) Silverfish (talk) 23:41, 22 November 2015 (UTC)

Discussion

Batting style

   Not done
Descriptionwhether a cricketer bats left or right handed
Data typeItem
Template parameter"batting" in en:template:Infobox cricketer
Domaincricketers (occupation (P106):cricketer (Q12299841))
Allowed valuesright-handedness (Q3039938), left-handedness (Q789447)
ExamplePhillip Hughes (Q3381076) → left-handedness (Q789447), Ian Botham (Q982121) → right-handedness (Q3039938)
Sourceexternal reference, Wikipedia list article, etc.
Robot and gadget jobsimport from en.wp infoboxes
Motivation

This is a defining feature for cricketers. See also shooting handedness (P423) and playing hand (P741) for other sports and handedness (P552) generally (which is usually but no necessarily the same as batting style). Thryduulf (talk: local | en.wp | en.wikt) 15:32, 10 November 2015 (UTC)

Discussion
I suggest to merge shooting handedness (P423) and playing hand (P741) and define it as a general property of handedness in sports. --Pasleim (talk) 09:15, 11 November 2015 (UTC)
Merge and use the existing items, per Pasleim. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:10, 13 November 2015 (UTC)

Two issues with the above comments

  1. Maybe it is more the time for those who have created the properties to assist in their redefinition. If one looks at the talk page for the proposed property to change it is very specific in the components that apply. For a general user to go and to modify this could be problematic, and such a change needs some level of imprimatur or governing and declared process. Someone clueless making that redefinition is simply going to be problematic.
  2. What is the cricketer bats right-handed, and plays tennis left-handed. It is quite well-known for even professional cricketers to bat one side, and bowl the other (eg. Michael Clarke) so without some delicate redesigning of the property, the simple statement of merge is a simple fail.  — billinghurst sDrewth 04:03, 15 November 2015 (UTC)
    Use qualifier to define how the value is applied. Snipre (talk) 09:39, 4 December 2015 (UTC)
  3.   Oppose Snipre (talk) 09:39, 4 December 2015 (UTC)

  Not done Recommended to use other properties/qualifier.--Micru (talk) 21:51, 8 March 2016 (UTC)

team caps for local leagues

   Not done
DescriptionA number of appearances of player for every team he played with at local leauges.
Data typeNumber (not available yet)
Template parameteren:template:Infobox football biography caps
Domainperson
Allowed values0-1000
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceExternal reference, Wikipedia list article
Robot and gadget jobsthey should be allowed
Proposed byXaris333 (talk) 01:26, 3 May 2013 (UTC)

I am concerned about the name of this property. Different Wikipedia have different methods of choosing which matches do and don't go in the infobox, and I am take-my-car-if-I'm-wrong confident that we will not get a uniform consensus. Some Wikipedia go for the regular season of the league only, others for league + playoffs, others for league + playoffs + cups, and there are a couple of other deviations from these main categories. If we don't name this precisely enough, we will create a mess – English/German/French/Italian speaking editors would probably end up doing different things with the same parameter, and end users at individual wikis would have to painstakingly trawl through the values to work out which one is suitable for their wiki's purposes. I would suggest different properties for league and cup competitions, potentially one more for playoffs, plus one for total appearances. It may seem like overkill, but those three/four parameters would cover almost every conceivable use for this data. —WFC— 07:21, 3 May 2013 (UTC)

I change the name. Team caps for local leagues. Let see if this could be done, and then we could propose for cups, international legues etc. Xaris333 (talk) 12:17, 3 May 2013 (UTC)
Bonsoir, excuse me but i'm best in french :) Le problème est que chaque wikipedia fonctionne différement, les francophones comptent championnat + coupes dans l'infobox, les anglophones seulement le championnat, le problème vient également des sources, des sites ont parfois des divergences notamment pour les joueurs du passé, même chose pour les clubs : la différence entre club professionnel et amateur est faite dans les infobox joueurs dans fr.wikipedia pas dans en.wikipedia, les équipes B ne sont également pas indiquées sur fr. wki (sauf pour les pays où le club B est une filiale, exemple l'Espagne)--Remy34 (talk) 19:21, 5 May 2013 (UTC)
Ok. What do you suggest? We can and must find a global solution what we want to have on wikidata about team caps and goals. It would be really helpfull for users all over the world. Xaris333 (talk) 20:10, 5 May 2013 (UTC)
Je n'ai pas de suggestion ni d'idée, s'il existait un organisme central des statistiques de footballeur ce serait beaucoup plus simple...--Remy34 (talk) 07:38, 6 May 2013 (UTC)
une suggestion si recenser les sources statistiques de qualité pour remplir les données concernat les matchs - buts en championnat et dans les autres compétitions (coupes, play offs)--Remy34 (talk) 21:37, 7 May 2013 (UTC)

  Oppose Why a property so specific ? In my opinion, it would be more appropriate to have a property "Total matches played" that could be used as a qualifier of the property member of sports team (P54) but also as a qualifier of a new property "takes part in" when the value is a sport competition. With this structure, the "Total league caps" property is no longer needed and the syntax is simplified. Same goes for the "Team goals for local leagues" and "Total leagues goals" properties : a "Total points scored" property should do the trick and could also be used for other sports than only hockey, football, handball and water-polo. Casper Tinan (talk) 14:21, 8 February 2014 (UTC)

team goals for local leagues

   Not done
DescriptionA number of goals of player for every team he played with at local leauges.
Data typeNumber (not available yet)
Template parameteren:template:Infobox football biography goals
Domainperson
Allowed values0-300
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceExternal reference, Wikipedia list article
Robot and gadget jobsthey should be allowed
Proposed byXaris333 (talk) 01:26, 3 May 2013 (UTC)

My comments at team caps apply equally here. —WFC— 07:22, 3 May 2013 (UTC)

Same for me. My comments at team caps also apply here. Casper Tinan (talk) 14:22, 8 February 2014 (UTC)

total leagues caps

   Not done
DescriptionThe sum of the appearances of player for all the teams he played with (for former player, for local leauges).
Data typeNumber (not available yet)
Template parameteren:template:Infobox football biography totalcaps
Domainperson
Allowed values0-1000
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceExternal reference, Wikipedia list article
Robot and gadget jobsthey should be allowed
Proposed byXaris333 (talk) 01:26, 3 May 2013 (UTC)


total leagues goals

   Not done
DescriptionThe sum of the goals of player for all the teams he played with (for former player, for local leauges).
Data typeNumber (not available yet)
Template parameteren:template:Infobox football biography totalgoals
Domainperson
Allowed values0-1000
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceExternal reference, Wikipedia list article
Robot and gadget jobsthey should be allowed
Proposed byXaris333 (talk) 01:26, 3 May 2013 (UTC)

My comments at team caps apply to a certain extent here, in the sense that if we have multiple parameters for appearances, there would be multiple relevant totals. —WFC— 07:25, 3 May 2013 (UTC)

  Oppose See my comments about "Team caps".--Casper Tinan (talk) 14:24, 8 February 2014 (UTC)

first name identical to this family name

   Not done
Descriptiongiven first name that is the same as a last name. Use on items for last names.
Data typeItem
Domainsurnames/family names
Allowed valuesitems for given first names
ExampleSylvain (Q18001608) (family name): Sylvain (Q16281827) (given name)
Robot and gadget jobsChecking and correcting the "inverse of" relation with family name identical to this given name (P1533)
Motivation

As an inverse of family name identical to this given name (P1533) to make it easier navigation between both of them. Actually when a surname is added as a given name it can be hard finding which element should be connected there instead, when it is easy to find it in the other way. Agabi10 (talk) 12:14, 11 October 2015 (UTC)

Discussion
  •   Support for symmetry: if you like having it ;). To avoid having them mixed up or merged, P1533 is generally sufficient. --- Jura 13:18, 18 October 2015 (UTC)
  •   Oppose as creating inverse properties for their own sake bloats the database, makes items take longer to load and increases workload on contributors. Ideally, WD will eventually have support for true inverse properties which don't need to be individually entered and maintained, but instead automatically mirror to facilitate navigation within WD. I doubt that is coming any time soon, but creating a bunch of inverse properties just to facilitate navigation within WD is not a good plan. They are sometimes warranted, but in this case, I would have to say that family name identical to this given name (P1533) is sufficient. Note also that if there is both a family name and a given name that are the same, they should both be instances of a general name item that covers all applications of the name and this will give you a way to click-navigate from one to the other. Josh Baumgartner (talk) 23:40, 6 November 2015 (UTC)
  • Sorted to person from unsorted. Josh Baumgartner (talk) 23:41, 6 November 2015 (UTC)
  •   Question Josh Baumgartner I think that I don't understand what you mean. Even if in the future the software mirrors the symmetric properties still two properties will be required to know which property has to be mirrored with each of them (or a way to have more than one name in each property and choose the correct one, or even a renaming of properties to "name-surname relation" to make sense in both of the elements). Also I don't understand how family name identical to this given name (P1533) can be sufficient if the one I know is the surname and I don't know if a name element exists. Also having one element that combines the names and surnames spelled in the same way as you suggest to make it easier the navigation wouldn't bloat the database more than creating one property for that? As far as I know an element and a property are both one row in the database, and while the same property can be used in more than one element a new element will be needed for each couple. -- Agabi10 (talk) 21:07, 7 November 2015 (UTC)
    • @Joshbaumgartner: Still waiting an answer to my question. -- Agabi10 (talk) 17:33, 15 November 2015 (UTC)
    • @Agabi10: Regardless of whether or not such a technical development ever happens, I oppose this property as unnecessary bloat. In fact, I don't even see a purpose for family name identical to this given name (P1533) in a structured database, much less a needless reflection of it. However, it is there and if the structure of given and family names being subsets of a general name item isn't handy for you and you have to put a direct link between the two, then family name identical to this given name (P1533) would do it. There is no need to have to enter that information on both family and given name items. I'm not sure I understand your question about knowing the surname but not the other, since even with your proposal, you would have to know both family and given name to be able to create the statement, and if you know both then why not use family name identical to this given name (P1533)? Josh Baumgartner (talk) 01:16, 18 November 2015 (UTC)
    • @Joshbaumgartner: I agree with you in the reasoning that this property and family name identical to this given name (P1533) would be completely useless, but only in a state of the database where there is no type constraint violations in where a surname was used as a value for the name property or in the other way. I know that the people who adds the properties to any of the name/surname elements (even if it is me or any other) will have to know, at least for a moment, that there is an element created for the other one to be able to put the property. The thing is that if after them someone tries to correct constraint violations related to elements with that property where the incorrect one is put they will find it easier.
      I also know that the ideal solution would be that the suggestion drop down shows first a value with a name instance for a name property, and the same happens with all of the other properties, which, as far as I know at this moment is not necessarily true. This would decrease the number of violations. Having correct names and descriptions for all the entities in all the languages would also help, but that's too idealistic. Being able to search for a value without having to use external tools (even if Magnus' tools are great) would also make it all of this easier to find elements with family name identical to this given name (P1533) with the current element as a value.
      As you can see I know that there are more ways to solve it that are also technically possible, but at this specific moment I think that an inverse property is the most feasible one. At least now I understand better why you are opposing and even if the explanation doesn't make you change your mind at least I hope that now both of us are understanding what the other wanted to make clear.  – The preceding unsigned comment was added by Agabi10 (talk • contribs).
  •   Oppose per Josh B. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:16, 18 November 2015 (UTC)
  •   Oppose first names are commonly used as names, normally not the contrary :/ it would not be logical - and I agree first name and name being subsets of a general name. :) --Hsarrazin (talk) 09:45, 24 December 2015 (UTC)

  Not done Lack of support.--Micru (talk) 17:51, 27 February 2016 (UTC)

name

   Done: name (P2561) (Talk and documentation)
Descriptionname the subject is known by
Representsname (Q82799)
Data typeMonolingual text
Examplesee below

We currently have several name properties which apply to certain specific types of names. However, sources do not always provide such definition when they provide a name, so there is no way to create a claim for the subject's name and know for sure which property to use. An educated guess constitutes a certain amount of original research. A contributor might see 'John Smith' and assume that given name (P735) John and family name (P734) Smith are appropriate, but even as uncontroversial as this may be to a native English speaker, there are many different linguistic constructs for names and many do not conform to first-last format. Even if we do add properties to cover all of the different classes of name out there, we will still have cases where the exact type is unknown, so we need a super-property that covers all of the name properties:

There are various ways in which this property can be used:

In an ideal world, all values would eventually be sorted into appropriate sub-categories as sources are found to substantiate such claims. The reality is that much of this type of specific detail is not available for some subjects and therefore the overarching property is needed. Josh Baumgartner (talk) 22:45, 20 October 2015 (UTC)

Discussion
  • Why not just have a different property for each type of name, instead of the P794 (P794) business? There aren't even a dozen of them, I think. --Yair rand (talk) 23:11, 20 October 2015 (UTC)
    • @Yair rand: That is what I thought at first, but what do you do when you know it is their name (per your source), but it is not clear what class of name it falls under (because your source does not specify)? You are left to guess, which is not appropriate for a sourced statement. The other problem is that not all name classes have their own properties, and it is possible that the community will deem some of them too specific to warrant their own property. I actually would support a broad set of such properties, but there are cases where the right one does not exist. However, as I noted above, even if they all did, you still need this property to avoid invalid claims based on guessing. Josh Baumgartner (talk) 21:41, 21 October 2015 (UTC)
      • So, why the broad usage examples? I could support a property for situations where the name type just isn't known, but if you're specifying anyway, I don't see why this should be used. Also, the monolingual datatype is probably wrong. --Yair rand (talk) 22:02, 26 October 2015 (UTC)
        • @Yair rand: I'm not sure I understand your question, I am proposing that this be used in exactly that case: where the name type is not known (see the first example I show). As for monolingual datatype, I'm open as to how to do that better. Is a simple string a better plan? Josh Baumgartner (talk) 16:41, 28 October 2015 (UTC)
          @Joshbaumgartner: In the second example given above, you list "name <Leo Tolstoy>" along with the given name and family name properties. If the given name and family name are already specified, why the extra statement? Or am I reading the example incorrectly?
          Regarding datatype, the properties given name (P735) and family name (P734) both use the item datatype, which allows for more structured data (along with easier handling of multilingual issues, in my opinion). The "name" property would also need to be item datatype for other name properties to be subproperty of (P1647) of it, as suggested by Filceolaire below. --Yair rand (talk) 22:26, 28 October 2015 (UTC)
@Yair rand: Maybe the model of my second example won't prove to be how this is used, but even if that proves true, use for the first case is sufficient to warrant creation of this property. Also, details of how we apply subproperty of (P1647) is a discussion that does not necessarily relate to whether or not we should have the property. Making the datatype 'item' would be a huge burden to create an item for every permutation of a full name that might be cited. Josh Baumgartner (talk) 19:19, 18 November 2015 (UTC)
I don't think I understand the scope of the property. Are the examples above actual statements that would be added? If not, would the item Leo Tolstoy (Q7243) use this property at all? If so, what statements would there be? Could you give some more examples? --Yair rand (talk) 21:22, 2 December 2015 (UTC)
  • Strong   Support. We need this as a property for other names to be subproperty of (P1647) of to use with a "search including subproperties" function - when we finally get one. We need it so that when we specify two given names, three family names, a patronymic (property needed for this) we can show how all these are put together - sometimes birth name isn't right for this. Joe Filceolaire (talk) 22:21, 25 October 2015 (UTC)
  •   Support - Per Joe's comment immediately above. Can we add married name to the list, too? Dirtlawyer1 (talk) 06:17, 14 November 2015 (UTC)
  •   Support per Joe Filceolaire. Need a generic property where other could be subproperty of (P1647), including Jean Racine (Q742). --Hsarrazin (talk) 09:53, 24 December 2015 (UTC)
  •   Support easy to use. --La femme de menage (talk) 17:33, 23 January 2016 (UTC)
  •   Support. Essential. Thryduulf (talk: local | en.wp | en.wikt) 00:21, 25 January 2016 (UTC)

  Done @Joshbaumgartner, Yair rand, Dirtlawyer1, Hsarrazin, La femme de menage, Thryduulf:--Micru (talk) 17:40, 27 February 2016 (UTC)

@La femme de menage: Tu sais qui a traduit "name" en français ? "nom" en générique ça ne m'a pas l'air de correspondre au fait que toutes les propriétés de nommage deviennent des sous-propriété, ça voudrait dire que le nom de famille est un nom d'usage, ça collerait ? author  TomT0m / talk page 18:25, 1 March 2016 (UTC)
@Joshbaumgartner, Micru, Filceolaire, Thryduulf, Yair rand, Hsarrazin: I can see a problem here : the claim that given name is a subproperty of this property : it can't be a subproperty because of a datatype mismatch. It's expected for a subproperty to be of the same dataype than its parent properties, and item datatype is very much not a monolingual type. author  TomT0m / talk page 18:25, 1 March 2016 (UTC)


married name

   Done: married name (P2562) (Talk and documentation)
Descriptionmarried name
Data typeMonolingual text
Template parametervarious, often not distinguished from "full name"
Domainpersons
Allowed valuestext
ExampleHillary Clinton (Q6294) -> Hillary Clinton; Hillary Rodham Clinton; Hillary Rodham-Clinton; Svetlana Andropovna; Maria Garcia de Vega (full married names, per reliable sources)
Sourceexternal reference, Wikipedia article
Motivation

We already have the property "family name," but this does not distinguish between a woman's family name at birth and her later married name(s). We should have the ability to distinguish between the two. At present we can only enter married names in the "family name" property without explanation or distinction, or the "also known as" alias field also without explanation or distinction. Dirtlawyer1 (talk) 08:35, 19 October 2015 (UTC)

Discussion

This is the first time I have made such a request, and I am not familiar with all of the requested information items above. If you have questions, please ask. Please be patient with this rookie. Thanks. Dirtlawyer1 (talk) 08:35, 19 October 2015 (UTC)

This works only if you know the wedding day. --Pasleim (talk) 21:18, 19 October 2015 (UTC)
Or year, or any other vague span of time in which the name change may have happened. And if it's completely unknown, one should probably put start date: unknown anyway. --Yair rand (talk) 23:25, 19 October 2015 (UTC)
"family name" has datatype 'item' - it links to a surname item. The "married name" property proposed here is like birth name (P1477) in that the actual name is spelled out. This can still have family name (P734) as a qualifier. Joe Filceolaire (talk) 01:08, 9 December 2015 (UTC)
  •   Comment just to clarify (as there is no sample), for Q6294 would this read "Clinton" or "Hillary Clinton"? --- Jura 07:07, 20 October 2015 (UTC)
  • @Jura1: Well, sir, that's subject to negotiation, but I would suggest that the new property structure should parallel that of the existing "birth name" property, and be a complete name with the language specified. Married names often vary widely in structure, with the relatively simple taking of the husband's surname (e.g., Hillary Clinton), the creation of a compound name (e.g., Hillary Rodham-Clinton), the use of both husband surname and the wife's maiden surname as a middle name without hyphen (e.g., Hillary Rodham Clinton), a different feminine surname form in Russian and several other Slavic languages (e.g., Svetlana Andropovna), or Spanish married combined name forms (Hillary Rodham de Clinton). I'm sure there are numerous other cultural and linguistic variations with which I am unfamiliar, combined with what is often the complete choice of the parties in the relatively new scenario of same-sex marriages. I know that in several countries, such as Germany, the format of married names has been strictly regulated by law, while in most English-speaking countries, the only limitations are social customs, which have been evolving toward greater flexibility and variation since the 1960s. Dirtlawyer1 (talk) 13:08, 20 October 2015 (UTC)
  Comment yet one more naming property ? It's already complicate to choose a property in the list. I   Oppose. Use "begin date" / "end date" on the (approximate) mariage date and preferred rank on the name valid ATM. Let's use Wikidata data model powerfulness ! author  TomT0m / talk page 17:46, 20 October 2015 (UTC)
@TomT0m: I appreciate your opinion, but it ignores the simple fact that for the overwhelming majority of our subjects with married names, we have neither an exact date nor even a year of their marriage. Of course, the situation is even more complicated for persons who have been married more than once. We need a property that identifies and collects all married names of a subject person within a single property, and that provides the flexibility to address the multiple married name formats not only in English-speaking countries, but multiple countries and cultures around the world. Stuffing married names into the "family name" property -- which only permits the entry of single-word linked family names -- does not do that. Please see my comment @Jura1 above regarding examples of the multiple formats of married names around the globe; the "family name" property simply is not made to purpose. Thanks. Dirtlawyer1 (talk) 19:08, 20 October 2015 (UTC)
@Dirtlawyer1: "the "family name" property simply is not made to purpose" => See the study about names on the talkpage of WikiProject Name for the different naming schemes in the world. This IS NOT a problem about married names, this is about all naming scheme. A scecialized property for married named won't help at all. I don't see how such a property will help if there is no known date either. It's exactly the same problem. It's enough to put the last known name with the "preferred" rank, and to use end date qualifiers and maybe qualifier about the order in sequence if we have no name. author  TomT0m / talk page 19:15, 20 October 2015 (UTC)
  •   Support The advantage of having "married name" as a simple string parallel to birth name (P1477) is that this is very easy to extract and use (and very easy to understand). Any scheme that involves qualifiers immediately is made a lot harder to query -- even more so if one would then have to filter out any other reasons why a name might have been changed. In contrast with two simple properties for birth-name and married-name, it becomes very easy to see whether one of those fields is missing.<br?>I am not against making sure that the married family-name is also reflected as a value for family name (P734) -- just as the relevant family-name part of a birth name (P1477) would be reflected in that way. Having an explicit property for the full married name as a string, parallel to birth name (P1477), in fact makes it easier to achieve and maintain appropriate values for the family name (P734) property, because it then becomes easy to check that values corresponding to both the birth name (P1477) string and the married-name string are present -- when these two properties are known and distinct, then there ought to be the correspondingly appropriate number of distinct values for family name (P734). Jheald (talk) 19:45, 20 October 2015 (UTC)
    • @Jheald: This argument has little to do with "married name" as such, it would hold for the name of the person as well. Plus ... it's a lot worse. A person can be married several time, how would this work ? We would have to create a "second married name" ? This would be a property mess. For this, rename "name at birth" "full name", and use ranks and date, per the same reasoning I used above. author  TomT0m / talk page 20:03, 20 October 2015 (UTC)
      • @TomT0m: If we were to go down that route, it would make it very difficult to systematically extract birth names for a particular group of people. Having to use comparison operators on qualifier dates for a variety of full name values would kill query performance stone dead.
        Yes, there will be cases where there will be more than one married name. But in such cases one will usually want to extract all of them, and one can use an ORDER BY clause. On the other hand, one may well want the original birth name in a separate column, and that would be a total nightmare with the system you suggest. Jheald (talk) 21:20, 20 October 2015 (UTC)
        • @Jheald: I'm pretty sure it's not harder to do a min or max in SPARQL than to do an order by clause. (plus I'm pretty dubious that it's not really a usecase to extract birth names for a particular group of people. To extract the birth name or someone for its infobox OK, apart from that ... I really hate the proliferation of naming properties we can currently see pop down in the suggest list. You really have to be an expert to choose the right one. author  TomT0m / talk page 21:27, 20 October 2015 (UTC)
        • PS: It is possible, see http://rdf.myexperiment.org/howtosparql?page=GROUP%20BY for example. author  TomT0m / talk page 21:30, 20 October 2015 (UTC)
          • The point is that you are then relying on all of the date qualifiers to be in place and to be correct, simply to extract the birth name -- it's a lot more robust simply to have a birth name property, then you don't have to rely on any qualifiers to identify the right value.
            Yes, you could introduce an additional sub-query for each individual, to join in all the names and all the date qualifiers into the query, with an ORDER BY and a LIMIT 1 to extract the earliest (if all of the qualifiers are there and correct) -- but it makes a hell of a lot more work; plus you would probably have to hand-optimise it, because the auto-optimiser is a bit random when it comes to queries involving sub-queries. (A sub-query is needed rather than GROUP BY because one can extract the earliest date with GROUP BY and MIN(), but there's no obvious way to get the name that goes with it).
            Finally, I don't think it is unrealistic for users to potentially want a list of individuals that included a column of birth-names and a separate column of married names. Particularly for a print-out, that is very often exactly the format one wants. (Something like this tinyurl.com/nwwk6ny, though at the moment we're a bit short of data). Jheald (talk) 22:07, 20 October 2015 (UTC)
  • A further thought: it may make most sense to introduce the "married name" property as a qualifier to spouse (P26). This would be the way to most directly associate the property with the right dates (if available) and the right spouse. Jheald (talk) 22:35, 20 October 2015 (UTC)
    • @Jheald: Good thought, but that only works if (a) we know at least the common, if not full name of the spouse, and (b) the spouse field may be entered as a plain text string (not linked text) for non-notable spouses. Dirtlawyer1 (talk) 18:38, 21 October 2015 (UTC)
    • Not sure how this would work for Molly Meacher (Q1943636) or Angela Merkel (Q567). --- Jura 13:03, 26 October 2015 (UTC)
      • @Jura1: I will let Jheald speak for himself, but I believe that Angela Merkel's legal married name is "Angela Dorothea Merkel," in keeping with the German name laws. When Merkel divorced her first husband she kept the Merkel name, and did not take her second husband's name when she remarried in 1998 (presumably because she was already well known publicly and politically as "Angela Merkel"). Had Merkel taken her second husband's name, as an example, the proposed property should be able to accommodate additional married names from second and third marriages, etc. Molly Meacher's legal married name is "Molly Christine Meacher," which appears to be relatively straightforward. Dirtlawyer1 (talk) 21:15, 26 October 2015 (UTC)
  •   Oppose per Yair rand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 23 October 2015 (UTC)
  • Strong   Support. Saying <family name:Clinton> with a start date doesn't tell us if her married name is Hilary Clinton or Hilary Rodham-Clinton or Hilary Clinton Rodham. We need this property with text datatype to specify the name she uses. 'Family name' can then be a qualifier to 'married name' to show what family names she uses since she is married with a different set of 'family names' as qualifier to her birth name. Joe Filceolaire (talk) 22:28, 25 October 2015 (UTC)
  •   Support, but it will need to be clarified that it is to be the full name, not just the assumed family name (or we can do it that way and make it 'item' datatype in line with 'family name'). Josh Baumgartner (talk) 01:22, 18 November 2015 (UTC)
    • Josh, it is intended that the datatype be text (not a linked item) and that the full married name be used, not just the assumed family name. Because of the various different types and forms of married names -- e.g., husband's family name, compound-hyphenated name, feminine version of husband's family name, maiden name as middle name + husband's family name, etc. -- the simplest and most accurate way to enter the name in every instance is text format. As it is, we do not have items for every surname. Dirtlawyer1 (talk) 14:05, 18 November 2015 (UTC)
    • Maybe "full married name" would be a better label to use to make it clearer. - Nikki (talk) 21:07, 19 February 2016 (UTC)
  •   Support, Some women can be married up to 10 times, think Bonnie Lee Bakley, and get a new name each time, or they may carry over the surname of the previous husband and hyphenate it with the new husband. --Richard Arthur Norton (1958- ) (talk) 18:44, 19 February 2016 (UTC)
  •   Support - Brya (talk) 17:27, 27 February 2016 (UTC)

  Done @Dirtlawyer1, Yair rand, Pasleim, Jura1, TomT0m, Pigsonthewing:@Joshbaumgartner, Nikki, Richard Arthur Norton (1958- ), Brya, Jheald:--Micru (talk) 17:50, 27 February 2016 (UTC)

Québec cultural heritage directory people identifier

Descriptionpeople listed on the Répertoire du patrimoine culturel du Québec
Representsrépertoire du patrimoine culturel du Québec (Q3456276)
Data typeExternal identifier
Domainperson (Q215627), human (Q5)
Allowed values\d{4,5}
ExamplePierre Gauvreau (Q22342916) → 7545
Sourcehttp://www.patrimoine-culturel.gouv.qc.ca/rpcq/rechercheProtege.do?methode=afficher
Formatter URLhttp://www.patrimoine-culturel.gouv.qc.ca/rpcq/detail.do?methode=consulter&id=$1&type=pge
Motivation

This property will can be usefull to source a architecte to a house he made, or a historic people to the house he lived. The property url and a the constraint are different of Quebec cultural heritage directory ID (P633). Fralambert (talk) 14:22, 31 January 2016 (UTC)

  Support seems pretty good. By the way, the example page cites biographi.ca which seems good too, I don't think we have any property for it at the moment either. -- – The preceding unsigned comment was added by Zolo (talk • contribs).
@Zolo:: If i check biographi.ca, it is not realy a ID, but it shoud be fesable to create a string property (ex.: Ludger Duvernay (Q3266045) --> duvernay_ludger_8F) --Fralambert (talk) 16:33, 31 January 2016 (UTC)
@Zolo:   Done with Québec cultural heritage directory people identifier (P2592) --Fralambert (talk) 18:00, 6 March 2016 (UTC)

National-Football-Teams.com player id

Template parameterpid in en:template:NFT_player and other language equivalents.
Domainhuman (Q5)
Robot and gadget jobsMy bot can import values from Wikipedias
Motivation

One of the last (I think) major football databases, useful for references. Edgars2007 (talk) 14:14, 13 February 2016 (UTC)

Discussion

I've already suggested it in the Person category (Wikidata:Property_proposal/Person#National-Football-Teams.com_player_id). I'm not sure which section (Authority Control or Person) is better, to be honest. Silverfish (talk) 18:13, 13 February 2016 (UTC)

Oh, didn't notice it. Well, all those external identifiers have been proposed here. But we could merge these requests. --Edgars2007 (talk) 19:28, 13 February 2016 (UTC)
I don't know what the procedure would be to merge proposals, but I   Support your proposal for this. I'll link to this proposal from my proposal, and withdraw it, as I think this version is probably better. I've change the name to National-Football-Teams.com player id as it's less ambiguious, and added a description and template parameter. Silverfish (talk) 23:20, 19 February 2016 (UTC)

@Edgars2007, Silverfish:   Done National-Football-Teams.com player ID (P2574) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 3 March 2016 (UTC)

B2Q Bibliothèque et Archives nationales du Québec (BAnQ) indentity

   Not done
DescriptionAuthority control for the Bibliothèque et Archives nationales du Québec (BAnQ)
RepresentsBibliothèque et Archives nationales du Québec identifier (Q22916615)
Data typeExternal identifier
Domainpeople, documents
Allowed valuesnumeric
Example0000050788 → United States Declaration of Independence (Q127912)
SourceVIAF
Motivation

Full property being linked to by VIAF Hazmat2 (talk) 16:54, 22 February 2016 (UTC)

Discussion

  Oppose According to the VIAF partner page the authority file is not online and I have not been able to find anything sensible by the number "0000015804" in the B2Q catalogues. Thus VIAF would be our only source and we neither could verify the number nor do something meaningful with it. -- Gymel (talk) 22:10, 24 February 2016 (UTC)

  Not done Per Gymel.--Micru (talk) 14:08, 4 March 2016 (UTC)

Latvian Olympic Committee athlete ID

Domainhuman (Q5)
Robot and gadget jobsMy bot can import values from Wikipedias
Motivation

Useful source for Olympic athletes from Latvia; used widely in Latvian Wikipedia. Would like to match these entries to Wikidata items. --Edgars2007 (talk) 12:04, 26 February 2016 (UTC)

Discussion

If somebody wants to say, that this is minor database/property, then I would like to note, that we already have ID for Sweden (Swedish Olympic Committee athlete ID (P2323)). But I understand, that Latvia isn't Sweden ;) --Edgars2007 (talk) 12:20, 26 February 2016 (UTC)

  •   Support Good external source for this topic. --Papuass (talk) 20:49, 1 March 2016 (UTC)

@Edgars2007, Papuass:   Done, see Latvian Olympic Committee athlete ID (P2593) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:25, 7 March 2016 (UTC)

Code for Indonesian Administrative Division

DescriptionUnique identification code for administrative division of the Republic of Indonesia
Data typeExternal identifier
Domainsettlements in Indonesia
Allowed valuesfour numbers separated by decimal point
ExampleWatuagung (Q13098442) → 33.22.06.2008
Sourcehttp://www.kemendagri.go.id/pages/data-wilayah
Motivation

Volunteers from Wikipedia Indonesia plan to add all list of identifiers, creating new item when necessary. Beeyan (talk) 10:20, 29 February 2016 (UTC)

Discussion

  Done @Siska.Doviana, Rachmat04, Mariyanah: --Micru (talk) 14:25, 5 March 2016 (UTC)

Statistics Indonesia ethnicity code

Descriptionethnicity code in Indonesia by Statistics Indonesia
Data typeExternal identifier
Domainethnicity in Indonesia
Allowed valuesfive digits, the last digit separated by space
ExampleJavanese people (Q49209) → 0114 6
Sourcehttp://microdata.bps.go.id/mikrodata/index.php/catalog/SP
Motivation


Volunteers from Wikipedia Indonesia plan to add all list of ethnicities from Statistics Indonesia Beeyan (talk) 10:37, 29 February 2016 (UTC)

Discussion
  •   Strong support would be interesting to add Siska.Doviana (talk) 07:20, 1 March 2016 (UTC)
  •   Strong support ··· 👦 Rachmat04 · 💬 04:06, 2 March 2016 (UTC)
  •   Strong support Mariyanah (talk) 07:47, 3 March 2016 (UTC)
  •   Comment If it's an external id, we need a formatter URL and the example should contain a full link (and only show the id). Mbch331 (talk) 18:21, 4 March 2016 (UTC)
    • Actually, we don't.
      --- Jura 07:43, 5 March 2016 (UTC)
    • Hello @Mbch331:, it's PDF file. It doesn't have a formatted URL. --Beeyan (talk) 08:05, 5 March 2016 (UTC)

  Done @Siska.Doviana, Rachmat04, Mariyanah: --Micru (talk) 14:25, 5 March 2016 (UTC)

Statistics Indonesia language code

Descriptionlanguage code in Indonesia by Statistics Indonesia
Data typeExternal identifier
Domainlanguage in Indonesia
Allowed valuesfive digits, the last digit separated by space
ExampleJavanese (Q33549) → 0088 3
Sourcehttp://microdata.bps.go.id/mikrodata/index.php/catalog/SP
Motivation

Volunteers from Wikipedia Indonesia plan to add all list of languages from Statistics Indonesia Beeyan (talk) 10:38, 29 February 2016 (UTC)

Discussion
  •   Strong support Yes, it is needed so we can start adding data Siska.Doviana (talk) 07:21, 1 March 2016 (UTC)
  •   Strong support ··· 👦 Rachmat04 · 💬 04:06, 2 March 2016 (UTC)
  •   Strong support Mariyanah (talk) 07:48, 3 March 2016 (UTC)
  •   Comment If it's an external id, we need a formatter URL and the example should contain a full link (and only show the id). Mbch331 (talk) 18:20, 4 March 2016 (UTC)
    • Hello @Mbch331:, it's PDF file. It doesn't have a formatted URL. --Beeyan (talk) 08:06, 5 March 2016 (UTC)

  Done @Siska.Doviana, Rachmat04, Mariyanah: --Micru (talk) 14:25, 5 March 2016 (UTC)

ASF KID Cave Tag Number

   Not done
DescriptionUnique identifier for caves within the Karst Index Database of the Australian Speleological Federation
Representscave (Q35509)
Data typeString
Template parameterNo parameters known to exist, however a new parameter could be added to en:template:infobox cave
Domaincave (Q35509)
Allowed valuesstring pattern: ([A-Z]|\d){1-3}\-X?\d+
ExampleMammoth Cave (Q10954073) → 6WI-38
SourceKarst Index Database of the Australian Speleological Federation
Robot and gadget jobsManual import is most likely
Motivation

Most of the information known about caves within Australia is held by numerous caving clubs/societies, with the ASF hosting a database (KID) which aims to collate the knowledge held by clubs into one shared source. The database contains a list of caves known within Australia, as well as detailed data on the characteristics of each cave (length, depth, features, date of discovery, etc). Caves usually have a little metal tag at the entrance stating the cave area code and serial number of the cave within the area. This unique identifier is referred to in literature published by speleological/caving societies, on maps and in books. Dhx1 (talk) 03:59, 22 November 2015 (UTC)

Discussion

  Not done Lack of support.--Micru (talk) 21:59, 9 March 2016 (UTC)

Boundary

   Not done
DescriptionLink to a GeoJSON file describing the boundary of the place.
Data typeURL
Domaingeographical feature (Q618123)
Allowed valuesFile should contain a polygon or multipolygon corresponding to the boundaries of the geographical location.
ExampleBoston (Q100) → http://example.org/Boston.json
SourceWikimedia Commons
Motivation

I want to programmatically get shapes for use in interactive maps such as the one demonstrated in mw:Extension:Graph/Interactive_Graph_Tutorial.

Discussion

Maybe properties would be more useful than links, so it would be easy to write a single query that fetches a whole group of place boundaries along with another property such as ISO code.  – The preceding unsigned comment was added by Ejegg (talk • contribs).

  •   Oppose using the URL datatype. This should use the GeoShapes datatype when it becomes available. --Yair rand (talk) 22:24, 21 January 2016 (UTC)

  Not done --Micru (talk) 14:05, 27 February 2016 (UTC)

  • @Micru: Seems a bit early to close as "not done".
    --- Jura 19:50, 1 March 2016 (UTC)
@Jura: The oppose reason seemed quite conclusive to me. Do you have further arguments? I can reopen it if you wish to add something.--Micru (talk) 22:24, 1 March 2016 (UTC)
If there are such files at Commons, I don't see why we couldn't have some sort of a link to retrieve them. It's not even sure if phab:T57549 is ever to be done.
--- Jura 22:29, 1 March 2016 (UTC)
@Jura1: Can you please tell me where are the json files in Commons? I was unable to find them...--Micru (talk) 10:14, 5 March 2016 (UTC)
@Micru: It says so in the proposal, let's ask its author @Ejegg:
--- Jura 16:19, 5 March 2016 (UTC)

Number of out of school children

Domaincountries, regions
SourceInitial import from http://data.uis.unesco.org/ UNESCO Institute for Statistics, could include other sources.
Motivation

Useful information about the level of education, can be applied to countries, regions etc, initial import of data from the UNESCO Institute for Statistics. This is part of my work as Wikimedian in Residence at UNESCO. John Cummings (talk) 09:29, 3 February 2016 (UTC)

Discussion
  •   Comment if you want to import a series of fields, please draw a list, map them to existing characteristics and then propose any missing ones. I don't think we should repeat the NIOSH experience. For identifiers, I'd just go ahead on propose them.
    --- Jura 04:46, 4 February 2016 (UTC)
@Jura1: Can you explain what you mean by 'the NIOSH experience'? John Cummings (talk) 08:51, 4 February 2016 (UTC)

I plan to import some of the data from the UNESCO UIS database starting with the education data.

The plan for this property would be to add claims to countries using the following qualifiers:

  1. Male or female
  2. Primary age
  3. Lower secondary age
  4. Pre Primary education
  5. Year with the oldest data would come from 1999 and the most recent is in most cases from 2014

Not all data is available for all countries on all dates John Cummings (talk) 10:30, 15 February 2016 (UTC)

@John Cummings:   Done number of out-of-school children (P2573) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 3 March 2016 (UTC)

@Pigsonthewing:, thanks very much Andy. John Cummings (talk) 15:32, 3 March 2016 (UTC)

Australian Wetlands Database Directory of Important Wetlands Reference Code

DescriptionIdentifier of an important Australian wetland listed in the Australian Wetlands Database Directory of Important Wetlands managed by the Australian Government Department of the Environment
Representswetland (Q170321)
Data typeExternal identifier
Template parameterNo existing property is known to exist, and no wetland infobox is known to exist. Perhaps en:template:Designation list could be updated
Domainwetland (Q170321) where located on terrain feature (P706) = Australia (Q3960) (approximation only)
Allowed valuesstring pattern: (ACT|VIC|NSW|SA|TAS|QLD|WA|NT|EXT)\d+
ExampleGinini Flats Wetlands Ramsar Site (Q5563129) → ACT002
SourceAustralian Wetlands Database » Directory of Important Wetlands
Formatter URLhttp://www.environment.gov.au/cgi-bin/wetlands/report.pl?smode=DOIW&doiw_refcodelist=$1
Robot and gadget jobsIt may be possible to scrape IDs from the database and then import into Wikidata using mix-and-match
Motivation

The Australian Wetlands Database Directory of Important Wetlands is the authoritative reference managed by the Australian Government Department of the Environment listing important wetland (Q170321)s within Australia (Q408). Within the database, numerous fields of additional data exist such as location, area, elevation, wetland type, various descriptions and justification for categorisation as an important wetland. Approval of this property would significantly enhance Wikidata's understanding of Australian wetlands (natural environment), and increase understanding of the Ramsar Convention (Q170170). Dhx1 (talk) 11:22, 22 November 2015 (UTC)


Discussion
  Support Seem usefull. --Fralambert (talk) 04:12, 4 February 2016 (UTC)
  Support. author  TomT0m / talk page 18:25, 22 February 2016 (UTC)
@TomT0m, Dhx1:   Done --Fralambert (talk) 03:06, 5 March 2016 (UTC)

INSEE region code

Descriptionnumber sequence for the identification of regions in France
Data typeExternal identifier
Domainregion of France (Q36784)
Allowed valueschaîne de caractères
ExampleBrittany (Q12130) → 53
Format and edit filter validation2-digit number between 01 and 94 (\d{2})
Sourcehttp://www.insee.fr/fr/methodes/default.asp?page=nomenclatures/cog/codes_regions_2016.htm
Motivation

We already have other identifiers from the Code officiel géographique : INSEE municipality code (P374) for communes and INSEE canton code (P2506) for cantons. This proposal fills the gap for regions. Ash Crow (talk) 14:46, 27 February 2016 (UTC)

Discussion
  Support. But this is of limited use, really. Thierry Caro (talk) 18:26, 1 March 2016 (UTC)
  Support --Fralambert (talk) 23:12, 3 March 2016 (UTC)
@Ash Crow, Thierry Caro:   Done C'est fait. --Fralambert (talk) 03:38, 5 March 2016 (UTC)


INSEE departement code

Descriptionnumber sequence for the identification of departements in France
Data typeExternal identifier
Domaindepartment of France (Q6465)
Allowed valueschaîne de caractères
ExampleCôtes-d'Armor (Q3349) → 22
Format and edit filter validation2-digit number between 01 and 19 or between 21 and 95, or values 2A, 2B, 69D, 69M, 3-digit number starting with 97 or 98.
Sourcehttp://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement/2015/txt/depts2015.txt
Motivation

We already have other identifiers from the Code officiel géographique : INSEE municipality code (P374) for communes and INSEE canton code (P2506) for cantons. This proposal fills the gap for departements. Ash Crow (talk) 14:52, 27 February 2016 (UTC)

Discussion
  Support. Thierry Caro (talk) 18:26, 1 March 2016 (UTC)
  Support. --Fralambert (talk) 23:24, 1 March 2016 (UTC)
@Ash Crow, Thierry Caro:   Done --Fralambert (talk) 03:47, 5 March 2016 (UTC)

driving side

   Withdrawn
DescriptionWhether vehicles in a state must drive on the left, or the right.
Data typeItem
Domainsovereign states
Allowed valuesleft (Q13196750) or right (Q14565199) (or dedicated items)
ExampleUnited Kingdom (Q145) → left (Q13196750)
Motivation

Basic but essential info. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 4 March 2016 (UTC)

Discussion
  •   Support, although the domain should be geographic regions rather than sovereign states as e.g. Gibraltar and Hong Kong drive on the opposite side to the United Kingdom and China respectively. This could also be done with instance of (P31) and an item "region where traffic drives on the left" (or right) I suppose, but that feels clumsier. Either way applies to part (P518) should be available as a qualifier. Thryduulf (talk: local | en.wp | en.wikt) 14:56, 4 March 2016 (UTC)

ːWe have driving side (P1622), what else is that used for? -- Innocent bystander (talk) 15:11, 4 March 2016 (UTC)

Withdrawn - I missed driving side (P1622), sorry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:24, 4 March 2016 (UTC)

topographic prominence

   Withdrawn
DescriptionFor any given summit, this would store how higher it is than its highest base.
Representstopographic prominence (Q656751)
Data typeNumber (not available yet)
Domainmountain (Q8502)
Allowed valuesFrom 0 to 8,848 m, which is the highest possible value, the one that applies to Mount Everest (Q513).
ExamplePico da Neblina (Q739484) → 2,886 m
Motivation

When it comes to numbers, mountains should not be dealt with only by looking at their altitude. We should store other data such as topographic prominence (Q656751). Thierry Caro (talk) 11:00, 27 February 2016 (UTC)

Discussion

Eventually, we can probably use height (P2048) with qualifiers. Thierry Caro (talk) 20:38, 1 March 2016 (UTC)

  Comment Except for Everest, not sure if it's that useful to combine the two in the same field.
--- Jura 21:05, 1 March 2016 (UTC)
There is no mixing because elevation above sea level (P2044) is for altitude. Thierry Caro (talk) 01:13, 2 March 2016 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Archive/45&oldid=1102554523"