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 or parts (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
John Samuel
Jeremy Dover
Toni 001
  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
DePiep
RShigapov
  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 series (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
DePiep
RShigapov
  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
Adriano Rutz
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
John Samuel
Jeremy Dover
Toni 001
  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
DePiep
RShigapov
  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
Adriano Rutz
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
John Samuel
Jeremy Dover
Toni 001
  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
DePiep
RShigapov
  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
Domainradio 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)