Wikidata:Property proposal/Archive/45
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
Description | person responsible for the overall look of a filmed event |
---|---|
Represents | production designer (Q2962070) |
Data type | Item |
Template parameter |
|
Domain | film (Q11424), television program (Q15416) |
Allowed values | human (Q5) |
Example | Gone with the Wind (Q2875) → William Cameron Menzies (Q261997) Mad Max: Fury Road (Q1757288) → Colin Gibson (Q22075468) |
Robot and gadget jobs | import 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
Description | User name of a person, or organisation, on YouTube |
---|---|
Data type | String |
Domain | human (Q5), organization (Q43229) |
Example | Avril Lavigne (Q30449) => avrillavigne |
Source | YouTube |
Formatter URL | https://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)- Well, this is YouTube's problem, not our. Visite fortuitement prolongée (talk) 19:10, 22 July 2015 (UTC)
- I'd argue that if the URL doesn't have the
/user/
component, it's not a user name; but please provide some examples of the other types. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 22 July 2015 (UTC) - Postscript: For example the channel https://www.youtube.com/channel/UCgm_rpJcdNaeNNG4JiiZjZg is operated by user https://www.youtube.com/user/suetanka - and https://www.youtube.com/suetanka redirects to the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 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)
- 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's not clear that either of those is for the person, rather then the campaign. YouTube does not appear to use a
- 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)
- That wouldn't work for the Donald Trump sample, try https://www.youtube.com/user/DonaldTrump --- Jura 13:19, 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)
- 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
- 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)
- Oppose This proposal follows the approach of X 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)
- @Pasleim: As I explained above, (in July!), https://www.youtube.com/suetanka (for example) redirects to https://www.youtube.com/user/suetanka Do you have a counter example, where this pattern does not apply? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 2 November 2015 (UTC)
- I'm really glad you ask this question. It helps evaluating your votes on the other proposals. --- Jura 13:26, 2 November 2015 (UTC)
- @Pigsonthewing: https://www.youtube.com/DonaldTrump does not redirect to https://www.youtube.com/user/DonaldTrump --Pasleim (talk) 13:34, 2 November 2015 (UTC)
- As I said above (also in July!) "It's not clear that [that] is for the person, rather then the campaign". Do you have any examples involving personal pages? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:51, 20 November 2015 (UTC)
- Would you happen to have anything to support your talk? --- Jura 17:28, 2 December 2015 (UTC)
- As I said above (also in July!) "It's not clear that [that] is for the person, rather then the campaign". Do you have any examples involving personal pages? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:51, 20 November 2015 (UTC)
- @Pasleim: As I explained above, (in July!), https://www.youtube.com/suetanka (for example) redirects to https://www.youtube.com/user/suetanka Do you have a counter example, where this pattern does not apply? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 2 November 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)
- 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)
Not done Consensus not reached.--Micru (talk) 13:29, 27 February 2016 (UTC)
YouTube address
Description | Channel address/User name/address of a person, or organisation's YouTube feed [6] |
---|---|
Data type | URL |
Domain | human (Q5), organization (Q43229) |
Allowed values | URLs starting with https://youtube.com/ |
Example | Avril 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)
- Reject proposal, for the same reasons as discussed in the context of the identifier proposals. As for "lost with too many concurring [sic] properties", we have a number of other property sets where there are multiples (see property:P1217 to 1220; property:P1233 to 1235 and 1239; and a handful of others).
Why are you opening a second discussion while the first is still underway? --Izno (talk) 17:39, 23 July 2015 (UTC)
- It's actually the 3rd, not the 2nd. --- Jura 18:01, 23 July 2015 (UTC)
- Oppose per proposals above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 23 July 2015 (UTC)
- Support URL datatype is not pretty but I don't see how to deal with all different URL formats when using string properties. --Pasleim (talk) 19:42, 4 October 2015 (UTC)
- Oppose For https://www.youtube.com/DonaldTrump use https://www.youtube.com/channel/UCAql2DyGU2un1Ei2nMYsqOA . Visite fortuitement prolongée (talk) 20:45, 7 October 2015 (UTC)
- @Visite fortuitement prolongée: That would actually be an argument to support the previous proposal (#2) and oppose the initial proposal (#1). Just bear in mind the scheme <domain>/<name> replaced <domain>/user/<username> --- Jura 09:36, 8 October 2015 (UTC)
Not done Consensus not reached.--Micru (talk) 13:31, 27 February 2016 (UTC)
Baike.com entry
Description | Entry in Baike.com (Hudong) encyclopedia |
---|---|
Represents | baike.com (Q1203487) |
Data type | String |
Domain | all |
Allowed values | Chinese text |
Example | Jiang Zemin (Q16597) → 江泽民 |
Format and edit filter validation | check that it's a real account |
Formatter URL | http://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
- Oppose. Use described by source (P1343). --Yair rand (talk) 03:35, 13 August 2015 (UTC)
- Use described by source (P1343) where this encyclopedia is a good source but have an authority control property like this proposal as well.
- 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)
- @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)
- 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)
- We already have other properties which are wiki page titles, e.g. IMSLP ID (P839), CPDL ID (P2000), page at OSTIS Belarus Wiki (P2490) and of course all the Commons ones like Commons category (P373) - what makes this one different? - Nikki (talk) 00:22, 14 February 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
Description | Standard unit for the quantity measured by this unit |
---|---|
Data type | Item |
Domain | unit of measurement |
Allowed values | unit of measurement (Q47574) |
Example | millimetre (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)
- 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)
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)
- "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)
- 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)
- ;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: 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é
Not done Consensus not reached.--Micru (talk) 13:34, 27 February 2016 (UTC)
toll
Description | fee or toll payable to use the subject |
---|---|
Represents | fee (Q11765) |
Data type | Number (not available yet) |
Template parameter | "toll" in en:Template:Infobox bridge |
Domain | bridges, tunnels, roads |
Allowed values | positive numbers with units of currency. Should have a qualifier of start time (P580) or point in time (P585) |
Example | Second Severn Crossing (Q1287969) 6.5 pound sterling (Q25224) (qualifier: start time (P580) 1 January 2015) |
Source | external reference, Wikipedia list article, etc. |
Robot and gadget jobs | import 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)
- Yes, but qualifiers can be used to give detail - e.g. applies to part, aspect, or form (P518) truck (Q43193) or valid in period (P1264) Sunday (Q132). Where a bridge uses classes comprising several vehicle types then items could be created and the main item use seal image (P158) "Class 1". Thryduulf (talk: local | en.wp | en.wikt) 01:48, 24 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)
- @Wittylama: The best way to tie objects in Wikidata to the equivalent in OSM is by tagging the OSM object (point, way, polygon or relation, as appropriate) with a Wikidata ID - as I've just done for SHB. The reverse is not sensible, as OSM IDs are not stable. The OSM wiki has details of tagging for opening hours, tolls, fees and charges. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:11, 1 December 2015 (UTC)
- direction (P560) exists so we can use that for the case of differential tolling, although we might need items for "northbound" etc. valid in period (P1264) rush hour (Q868252) can be used for the peak time tolls, but more granular that than we need new qualifiers "applies to period from" and "applies to period to" (or similar), which would be useful for more than just this property. Thryduulf (talk: local | en.wp | en.wikt) 14:48, 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
Description | fare or fee payable to use the subject |
---|---|
Represents | fare (Q1142227) |
Data type | Number (not available yet) |
Template parameter | ? |
Domain | public transport (Q178512) (trains, buses, funicular railways, etc.) |
Allowed values | positive numbers with units of currency. Should have a qualifier of start time (P580) or point in time (P585) |
Example | Bridgnorth Cliff Railway (Q4966907) 1.2 pound sterling (Q25224) (qualifier: point in time (P585) July 2015) |
Source | Wikimedia 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
Description | defining attribute, trait (or similar) which all instances of this class-type item will have. See [7]. |
---|---|
Data type | Item |
Domain | any class item (subclass of (P279)) |
Allowed values | broad scope |
Example | |
Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Source | Often just common knowledge, and normally mentioned in Wikipedia articles |
Robot and gadget jobs | Probably 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 characteristic (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(s) (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 characteristic (P1552), with preferred rank if it's really necessary. has characteristic (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)
- perfect. Unless Danrok notes a situation in which has characteristic (P1552) is not a good fit, I'll move to Oppose. Runner1928 (talk) 04:51, 12 January 2016 (UTC)
Not done Redundant.--Micru (talk) 13:40, 27 February 2016 (UTC)
autores.uy database id
Description | A unique identifier of uruguayan authors and artistic, scientific or literary works. |
---|---|
Data type | String |
Domain | Authors of artistic, scientific or literary works of Uruguayan nationality. |
Allowed values | [0-9]{5} |
Example | Mario Benedetti (Q16285) → 485 |
Source | http://autores.uy/ |
Formatter URL | http://autores.uy/autor/$1 |
Robot and gadget jobs | bots 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)
- Mabye you are right, and these numbers could not be stable. --Zerabat (talk) 15:46, 27 January 2016 (UTC)<
Done @Zerabat, Joshbaumgartner, Pepe piton, Zeroth:--Micru (talk) 17:09, 27 February 2016 (UTC)
First item in sequence
Description | First 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 type | Item |
Template parameter | "first"/"inaugural" in w:Template:Infobox_official_post |
Domain | items for series, offices, etc. |
Allowed values | items with a property linking to that series/position |
Example | w:President of the European Commission → w:Walter Hallstein (note the infobox on the linked page) |
Source | infoboxes |
Robot and gadget jobs | Harvest Templates (Q21914398) |
Proposed by | Jura 14:03, 7 January 2016 (UTC) |
- Discussion
- For three alternative solutions, see Wikidata:Project chat#First item of series.
- The above, seemingly anonymous, comment was added by Jura1, in his edit of 14:04 UTC today. He misplaced it, in the
|description=
field, despite him having been told previously not to include links there. Accordingly, I moved it here, together with a copy of his sig, so that the attribution was not lost. He removed the sig, so I added{{Unsigned}}
. He has now also removed that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:52, 7 January 2016 (UTC)
- The above, seemingly anonymous, comment was added by Jura1, in his edit of 14:04 UTC today. He misplaced it, in the
- Oppose As pointed out on project chat, by User:ValterVB and User:Yair rand respectively, Set follows (P155) to "no value" and/ or use series ordinal (P1545). Also, please use Q items, not Wikipedia links, for examples. And I've moved a misplaced editorial comment from the description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
- Oppose per Andy's coments. Josh Baumgartner (talk) 18:04, 7 January 2016 (UTC)
- Support. I'd also like to have a special property to link an element of a sequence to the item about the sequence, I think it's a mistake to use part of for this. author TomT0m / talk page 20:17, 7 January 2016 (UTC)
Not done Consensus not reached.--Micru (talk) 13:48, 27 February 2016 (UTC)
DEFAULTSORT
Description |
|
---|---|
Data type | String |
Template parameter | none, for categories only |
Domain | Person 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 validation | 1 to 3 strings following allowed values and options DEFAULTSORT 1 to 3 |
Robot and gadget jobs | A 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
Description | graphics processing unit within system |
---|---|
Represents | graphics processing unit (Q183484) |
Data type | Item |
Template parameter | Wikipedia infobox parameters, if any; ex: "population" in en:template:infobox settlement |
Domain | electronic devices eg computers, phones, gaming consoles etc |
Example | Xbox 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
Description | plural form of label |
---|---|
Data type | Monolingual text |
Domain | terms |
Example | second (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 in vacuum (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 in vacuum (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)
- 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.
- 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)
- @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 is actually a plan to do just that at Wikidata, as Wiktionary has some technological issues.
- 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
Description | Cylinder bore represents the size, in terms of diameter, of the cylinder in which a piston travels |
---|---|
Represents | bore (Q245657) |
Data type | Quantity |
Template parameter | "bore" in en:template:infobox_automobile_engine |
Domain | reciprocating engine (Q630010), compressors, other machines with pistons |
Allowed values | >0 |
Example | Wärtsilä-Sulzer RTA96-C (Q1625442) → 960 mm |
Robot and gadget jobs | consistency check (positive number with distance unit), import from infoboxes |
Description | Length of the motion in reciprocating engines and other mechanisms. |
---|---|
Represents | stroke (Q671554) |
Data type | Quantity |
Template parameter | "stroke" in en:template:infobox_automobile_engine |
Domain | reciprocating engine (Q630010), compressors, other machines with pistons |
Allowed values | >0 |
Example | Wärtsilä-Sulzer RTA96-C (Q1625442) → 2500 mm |
Robot and gadget jobs | consistency 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
Description | text describing how to use a property or item |
---|---|
Data type | Monolingual text |
Domain | mainly properties, some items where needed |
Example | male (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
Description | MISSING |
---|---|
Data type | Monolingual text |
Domain | everything |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
- 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
Description | Identifiers in the Women Writers database of the Institute of Netherlands History (Q1665263) |
---|---|
Data type | String |
Domain | person |
Allowed values | string of letters and numbers |
Example | Rijkje Bubbezon (Q1976101) → a86984df-a43a-4e12-bde2-f55e89c08cca |
Source | http://resources.huygens.knaw.nl/womenwriters |
Formatter URL | http://hdl.handle.net/11240/$1 |
Robot and gadget jobs | Would 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)
Nationalmuseum Sweden artist ID
Description | Artist identifier for Nationalmuseum in Sweden |
---|---|
Data type | External identifier |
Domain | Persons |
Allowed values | [0-9]\d{0,5} (1 to ~25000) |
Example | Carl Larsson (Q187310) → 3877 |
Source | external reference |
Formatter URL | http://collection.nationalmuseum.se/eMuseumPlus?service=ExternalInterface&module=artist&objectId=$1 |
Robot and gadget jobs | Bot 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
- Comment Perhaps name should be Nationalmuseum Sweden artist identifier, to avoid ambiguity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:58, 22 January 2016 (UTC)
- Makes sense. Changing the English name, leaving the Swedish one unchanged. /André Costa (WMSE) (talk) 10:41, 29 January 2016 (UTC)
- Support --Edgars2007 (talk) 08:15, 3 February 2016 (UTC)
- Support - definetly yes. Marcus Cyron (talk) 11:15, 18 February 2016 (UTC)
- @André Costa (WMSE), Edgars2007, Marcus Cyron: Done!! ArthurPSmith (talk) 15:57, 19 February 2016 (UTC)
Nationalmuseum Sweden artwork ID
Description | Artwork identifier for Nationalmuseum in Sweden |
---|---|
Data type | External identifier |
Domain | Artwork |
Allowed values | [0-9]\d{0,6} (1 to ~200000) |
Example | Midwinter's Sacrifice (Q761681) → 32534 |
Source | external reference |
Formatter URL | http://collection.nationalmuseum.se/eMuseumPlus?service=ExternalInterface&module=collection&objectId=$1&viewType=detailView |
Robot and gadget jobs | Bot 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
- Comment Perhaps name should be Nationalmuseum Sweden artwork identifier, to avoid ambiguity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:59, 22 January 2016 (UTC)
- Makes sense. Changing the English name, leaving the Swedish one unchanged. /André Costa (WMSE) (talk) 10:42, 29 January 2016 (UTC)
- Support --Edgars2007 (talk) 08:15, 3 February 2016 (UTC)
- Support - definetly yes. Marcus Cyron (talk) 11:15, 18 February 2016 (UTC)
- @André Costa (WMSE), Edgars2007, Marcus Cyron: Done! ArthurPSmith (talk) 16:03, 19 February 2016 (UTC)
Box Office Mojo franchise ID
Description | identifier of a film series or brand in the Box Office Mojo database |
---|---|
Represents | Box Office Mojo (Q223142) |
Data type | String |
Domain | film series (Q24856) |
Allowed values | [a-z0-9]+ |
Example | Marvel Cinematic Universe (Q642878) → avengers |
Source | http://www.boxofficemojo.com/franchises/ |
Formatter URL | http://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
- Support --Edgars2007 (talk) 08:15, 3 February 2016 (UTC)
- @Máté, Edgars2007: Done. Mbch331 (talk) 11:26, 8 February 2016 (UTC)
Box Office Mojo studio ID
Description | identifier of a film studio in the Box Office Mojo database |
---|---|
Represents | Box Office Mojo (Q223142) |
Data type | String |
Domain | film studio (Q375336), film production company (Q1762059) |
Allowed values | [a-z0-9]+ |
Example | Warner Bros. (Q126399) → warnerbros |
Source | http://www.boxofficemojo.com/studio/?view2=allstudios&p=.htm |
Formatter URL | http://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
- Support --Edgars2007 (talk) 08:15, 3 February 2016 (UTC)
- @Máté, Edgars2007: Done - Mbch331 (talk) 11:52, 8 February 2016 (UTC)
Aarne–Thompson–Uther Tale Type Index
Description | index used to classify folktales |
---|---|
Represents | Aarne–Thompson–Uther classification system (Q301545) |
Data type | String |
Template parameter | "Aarne-Thompson Grouping" in en:template:Infobox folk tale |
Domain | folk tale (Q1221280) |
Allowed values | numbers between 1 and ca. 2499, optional suffixes like A, B, C (the AT groupings are preceded with "AT") |
Example | Cinderella (Q11841) → 510 A |
Source | Multilingual Folk Tale Database |
Formatter URL | http://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)
- Strong support. Very important classification system. There's overlap in values with Iconclass notation (P1256) (e.g., http://iconclass.org/rkd/84(CINDERELLA)/) and it's important to have the literary classification alongside the artistic classification. Runner1928 (talk) 20:06, 4 February 2016 (UTC)
- Support Skim (talk) 15:21, 9 February 2016 (UTC)
- @Gobonobo, Runner1928, Skim, Phil wink: Done! ArthurPSmith (talk) 16:14, 19 February 2016 (UTC)
Acceptable daily intake (ADI)
Description | Estimate 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. |
---|---|
Represents | acceptable daily intake (Q680142) |
Data type | Number (not available yet) |
Domain | food additive |
Allowed values | numbers with units in amount per kilo |
Example | pentachlorobenzene (Q425468): 0.0167 mg/kg |
Source | External 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
Description | heat trapped by a certain gas in CO2 equivalents |
---|---|
Represents | global warming potential (Q901028) |
Data type | Number (not available yet) |
Template parameter | "GWP" in Infobox Chemikalie |
Domain | chemical compound (Q11173) and mixture (Q169336) |
Allowed values | number with year as unit |
Example | trichloromonofluoromethane (Q423000) → 5352, duration (P2047): 100 year |
Source | Global 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)
- Done this one. I leave the other to an admin or one of the above.
- @Micru, ArthurPSmith, Danrok, Jura1, Tobias1984: Please create this property. Snipre (talk) 13:20, 29 February 2016 (UTC)
Global-warming potential (20 years)
Description | heat trapped by a certain gas in CO2 equivalents |
---|---|
Represents | global warming potential (Q901028) |
Data type | Number (not available yet) |
Template parameter | "GWP" in Infobox Chemikalie |
Domain | chemical compound (Q11173) and mixture (Q169336) |
Example | trichloromonofluoromethane (Q423000) → 7020 |
Source | Global 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
Description | European Chemicals Agency (Q48798) puts together the most relevant information on individual chemical substances in so-called InfoCards. |
---|---|
Data type | External identifier |
Domain | chemical compound (Q11173) & mixture (Q169336) |
Allowed values | regexp: [0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9] |
Example | diethylhexyl phthalate (Q418492) → 100.003.829 |
Source | ECHA's list of registered substances (left column with link to InfoCard) → wikitable of that list |
Formatter URL | http://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.:
- Brief Profile
- CL Inventory
- EC Inventory
- Registered Substances
- Candidate List
- Authorisation List
- Restriction List
--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
Description | formula representing a theorem or law |
---|---|
Data type | Mathematical expression |
Domain | Mathematical and physics based articles |
Allowed values | LaTeX strings |
Example | Pythagorean 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
Notified participants of WikiProject Mathematics
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
Description | formula to calculate. Use variables, figures, and the following ASCII elements: */-+^. For more complex formula, use TeX (P1993) |
---|---|
Represents | formula (Q976981) |
Data type | String |
Allowed values | /*-+^ et variables |
Example | speed (Q21600451) → v = d/t |
Robot and gadget jobs | import 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- "Already existing support for TeX is irrelevant," is an unsubstantiated claim. It is entirely relevant.
- 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)
- 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.
- 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
Description | equation describet by the item |
---|---|
Represents | equation (Q11345) |
Data type | Mathematical expression |
Domain | items from Category:Equations (Q7156671) |
Example | Arrhenius equation (Q507505) → (see test) |
Source | usually 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
- Support I support a general property. --Molarus 07:34, 12 February 2016 (UTC)
- Support This seems like an important property for mathematical equations. --Lawrencetroup (talk) 16:31, 14 February 2016 (UTC)
- What's the difference with defining formula (P2534)? Mbch331 (talk) 10:25, 17 February 2016 (UTC)
- Oppose as duplicate of defining formula (P2534). Swpb (talk) 14:28, 17 February 2016 (UTC)
Duplicate of defining formula (P2534), this would be useless. --Epìdosis 14:43, 17 February 2016 (UTC)
amended by (en) / поправки в (ru)
Description | Document is amended by specified other document. |
---|---|
Data type | Item |
Domain | documents, legislative_enactments. |
Allowed values | (see above) |
Robot and gadget jobs | Tracking and search. |
Proposed by | Sfan00 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)
- Support Filceolaire (talk) 07:36, 30 November 2013 (UTC)
repealed by (en)
Description | Document is repealed/inactived by specified other document. |
---|---|
Data type | Item |
Domain | documents, legislative_enactments. |
Allowed values | (see above) |
Robot and gadget jobs | Tracking and search. |
Proposed by | Sfan00 IMG (talk) |
This property is intended to note ammendments made to a document by another document..
- Support Filceolaire (talk) 07:37, 30 November 2013 (UTC)
Contact times of eclipses
Description | Contact times of eclipses: P1, U1, U2, U3, U4, P4 |
---|---|
Data type | Point in time |
Domain | lunar and solar eclipses |
Allowed values | time in UTC |
Example | 6 April 2015, 03:22 UTC. qualifier <applies to part:U4 - solar eclipse> |
Source | Wikipedia 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)
- Done, although no corresponding items created yet MSGJ (talk) 09:22, 5 June 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)
- 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)
- 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)
Saros cycle of eclipse
Represents | saros series (Q220397) |
---|---|
Data type | Number (not available yet) |
Domain | lunar/solar eclipses |
Allowed values | a whole number between -20 and 183 |
Example | June 2029 lunar eclipse (Q6312134) => 130 |
Source | Wikipedia 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.
- @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)
- @Joshbaumgartner: Hi Josh, do you have any comments on the merits of this proposal? MSGJ (talk) 11:51, 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 type | Item |
Domain | qualifier to number datatype-properties |
Allowed values | 1 sigma/3 sigma etc |
Example | orbital eccentricity (P1096):0.8524512679233956; 1 sigma: 0.00028691 q:uncertainty corresponds to: 1 sigma |
Source | external references |
Description | A property to be used as qualifier, when the precision is described with standard deviation (Q159375) instead of +/- whatever |
---|---|
Represents | standard deviation (Q159375) |
Data type | Number (not available yet) |
Domain | as a qualifier to (almost) any number-datatype property |
Example | orbital eccentricity (P1096):0.8524512679233956; 1 sigma: 0.00028691 [10] |
Format and edit filter validation | the unit of this qualifier should be the same as the unit for the claim itself |
Source | external 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
- 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 σ)
- orbital eccentricity (P1096):
- --Leyo 09:43, 28 October 2015 (UTC)
- What about the following changes in your example above?
- 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)
Notified participants of WikiProject Physics
Notified participants of WikiProject Chemistry
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:
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
Description | indicates the characteristic climate of a place (Köppen climate classification). |
---|---|
Represents | Köppen climate classification (Q124095) |
Data type | Item |
Template parameter | Climate |
Domain | Any city, region, country, etc. |
Allowed values | One of the symbols of the Köppen climate classification. |
Example | San Francisco (Q62) → warm-summer Mediterranean climate (Q21578284) |
Source | Climate chart of the Wikipedia article of the place. |
Robot and gadget jobs | Bots 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
- Support --AmaryllisGardener talk 00:00, 13 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 16:13, 14 November 2015 (UTC)
- Support, this is a specific system of classification, so I would recommend labeling it as 'Köppen climate classification' (aka 'climate') to help users easily recognize its intended use. Josh Baumgartner (talk) 21:33, 17 November 2015 (UTC)
- Comment This is 1 of 2 open proposals for Köppen climate classification: /Place, /Natural science. Mrwojo (talk) 15:40, 27 November 2015 (UTC)
- I've closed the duplicate and pinged the participants to comment here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:08, 27 November 2015 (UTC)
- Comment There are, apparently, only around 30 defined types. These should be items, and the datatype changed to match. Also, there is a mismatch between the current "string" datatype and the example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:12, 27 November 2015 (UTC)
- Neutral I will support this property if it's only used with climate types according to Köppen. Mediterranean climate (Q13996) as used in the example, is not a climate type in the Köppen classification. --Pasleim (talk) 19:37, 27 November 2015 (UTC)
- I supported the other proposal, but I'm not happy with this one per Pasleim. Thryduulf (talk: local | en.wp | en.wikt) 23:44, 27 November 2015 (UTC)
- I agree. But there's no Wikidata element for Csb. I created warm-summer Mediterranean climate (Q21578284) but I can't link it to en:Warm-summer Mediterranean climate or fr:Climat supra-méditerranéen that are redirections. A455bcd9 (talk) 06:51, 28 November 2015 (UTC)
- Note: The description for this proposal refers specifically to Köppen climate classification (Q124095). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:01, 29 November 2015 (UTC)
- Support As previously stated by other users this should be rename Köppen classification (the most widely use classification). I will also support if it's named Köppen classification. The english wikipedia shows 3 other type of classification for climate https://en.wikipedia.org/wiki/Climate_classification. --Ben1978 (talk) 10:40, 28 February 2016 (UTC)
- Fine for me now --Ben1978 (talk) 10:40, 28 February 2016 (UTC)
- In an attempt to make some progress on this, I've updated the type (since the example was an item not a string), the example (since the proposer has since created the right item for the example, see above) and the name (since the description already indicates it's for the Köppen classification, the comments above seem to agree that it should be restricted to Köppen and another Köppen-specific proposal was closed as a duplicate of this). @A455bcd9: Are you ok with the changes? @Pigsonthewing, Pasleim, Thryduulf: Does the proposal look ok to you now? - Nikki (talk) 13:36, 22 February 2016 (UTC)
- looks good now, Support --Pasleim (talk) 14:32, 22 February 2016 (UTC)
- Support per Pasleim (again). Thryduulf (talk: local | en.wp | en.wikt) 17:39, 22 February 2016 (UTC)
- Support Thierry Caro (talk) 01:40, 27 February 2016 (UTC)
- Support @Nikki: I am! A455bcd9 (talk) 16:41, 27 February 2016 (UTC)
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
Description | Similar property to present in work (P1441) but for items that are only named in a work but not actually present in it. |
---|---|
Data type | Item |
Domain | fictional item (fictional character (Q95074), fictional location (Q3895768), fictional object (Q15706911)…) |
Allowed values | work (Q386724) source = infoboxes |
Example | Beren (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 jobs | Devrait-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)
- Oppose present in work (P1441) is useful for any time there is a meaningful mention of an item in a work. If an item is mentioned in a work, then it is present in the work, so having two different properties is just going to be confusing and lead to inconsistent use. Josh Baumgartner (talk) 17:44, 30 October 2015 (UTC)
- Comment: See also Wikidata:Property_proposal/Sister_projects#mentions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:14, 21 November 2015 (UTC)
Not done --Micru (talk) 14:08, 27 February 2016 (UTC)
production date / production year
Description | Date (year) of production (broadcasting; might also be used for films) |
---|---|
Data type | Point in time |
Template parameter | Produktionsjahr (PJ) in de:Vorlage:Infobox Hörspiel |
Domain | radio drama (Q2635894), radio documentary (Q2125867), ... |
Example | Du 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)
- 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.
- 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)
- @Jklamo:: P571 would be when production started.
- 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)
Description | Main literature about a person or a subject. |
---|---|
Data type | Item |
Domain | work |
Allowed values | books and articles |
Example | Oscar Wilde (Q30875) => Frank Harris: Oscar Wilde. His Life and Confessions. New York 1916. |
Proposed by | Kolja21 (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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- 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)
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)
- No, for these lists we have notable work (P800) (deWP: Schriften / "Further reading" = Sekundärliteratur). --Kolja21 (talk) 22:00, 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)
- 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)
- Sure, Kolja21 … Both never published something… --Succu (talk) 22:37, 27 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
Description | Ancient site or object is associated with this human culture |
---|---|
Represents | culture (Q11042) |
Data type | Item |
Template parameter | "cultures" in en:template:infobox ancient site |
Domain | archaeological/historic sites; archaeological finds |
Allowed values | any human cultures (Ancient Rome, Ancient Egypt, Inca Empire...) |
Example | Colosseum (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
Description | Author of front matter (including forewords, introductions, prefaces, etc.) of a book or other work |
---|---|
Data type | Item |
Domain | written works |
Allowed values | people |
Example | Phantoms in the Brain (Q2149841) → Oliver Sacks (Q258662) (with qualifier applies to part, aspect, or form (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
Description | number of a work by Johann Sebastian Bach in the Bach-Werke-Verzeichnis |
---|---|
Represents | Bach-Werke-Verzeichnis (Q214203) |
Data type | String |
Allowed values | numbers between 1 and ca. 1100, optional suffixes like a, b, c... (Anh. or deest would be expressed by qualifiers) |
Example | Der Geist hilft unser Schwachheit auf, BWV 226 (Q1193795) → 226 |
Source | w: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.
- Support. Runner1928 (talk) 18:12, 15 October 2015 (UTC)
- Oppose Seems to be minor. --Diego Grez-Cañete (talk) 05:16, 16 October 2015 (UTC)
- T.seppelt , I want to support this but the formatter url doesn't seem to work. Can you get the actual url for Der Geist hilft unser Schwachheit auf, BWV 226 (Q1193795) and add it to "source = "? so we can see what an actual url looks like? 06:19, 24 November 2015 (UTC)
- http://www.bach-digital.de/receive/BachDigitalWork_work_00000283 is the URL for Der Geist hilft unser Schwachheit auf, BWV 226 (Q1193795), which means the formatter URL should be http://www.bach-digital.de/receive/BachDigitalWork_work_$1 and the value should be 00000283. Just checked a random other work and it's indeed the formatter I thought it was followed by 8 digits. Updated the template to the correct values. Mbch331 (talk) 14:35, 24 November 2015 (UTC)
- Your changes make no sense; "00000283" is not a valid BWV number. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 7 December 2015 (UTC)
- @T.seppelt: you still want this property? Currently this request seems to be stale and has issues. Multichill (talk) 10:40, 9 January 2016 (UTC)
- I've removed the incompatible example and formatter URL. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 3 March 2016 (UTC)
- Your changes make no sense; "00000283" is not a valid BWV number. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 7 December 2015 (UTC)
- http://www.bach-digital.de/receive/BachDigitalWork_work_00000283 is the URL for Der Geist hilft unser Schwachheit auf, BWV 226 (Q1193795), which means the formatter URL should be http://www.bach-digital.de/receive/BachDigitalWork_work_$1 and the value should be 00000283. Just checked a random other work and it's indeed the formatter I thought it was followed by 8 digits. Updated the template to the correct values. Mbch331 (talk) 14:35, 24 November 2015 (UTC)
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
Description | ... |
---|---|
Represents | BabelNet (Q4837690) |
Data type | External identifier |
Domain | any item |
Example |
|
Source | http://babelnet.org |
Formatter URL | http://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 jobs | some 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)
- @Filceolaire, Magnus Manske:: the "RDF vs human URL" pattern appears in other datasets as well. Eg http://vocab.getty.edu/aat/300122745 is a web page, but it's just a dump of triples, and the scope note is not there (it's on a "sub-page" http://vocab.getty.edu/aat/scopeNote/113777). http://vocab.getty.edu/page/aat/300122745 (which redirects to the long & ugly http://www.getty.edu/vow/AATFullDisplay?find=&logic=AND¬e=&subjectid=300122745) is much better for human consumption. I think we need formatterURLdata in addition to the existing formatterURL. Mix-n-Match should continue to show formatterURL but can add a second link "(data)" when available. --Vladimir Alexiev (talk) 09:43, 18 September 2015 (UTC)
- I think we may need separate properties for different file types - formatter URL for HTML; formatter JSON URL; formatter RDF URL' etc. so software agents can find stuff. Wikidata:Property_proposal/Term#Data_Model is looking at something like this (I think). Joe Filceolaire (talk) 15:46, 18 September 2015 (UTC)
- Isn't that formatter URI for RDF resource (P1921)? I think the formatters for AAT mentioned in your example should be split and follow what has been done for GND or IdRef. Part of the answer to the above question is given at [11] --Nono314 (talk) 10:19, 19 September 2015 (UTC)
- @Nono314: Yes, formatter URI for RDF resource (P1921) is exactly what we need, as I see it's been applied to IdRef ID (P269). So I applied it to Art & Architecture Thesaurus ID (P1014), Getty Thesaurus of Geographic Names ID (P1667), Union List of Artist Names ID (P245). Not yet Cultural Objects Names Authority ID (P1669) since it doesn't yet have RDF representation --Vladimir Alexiev (talk) 12:14, 29 December 2015 (UTC)
Done @Vladimir Alexiev, Nono314: --Micru (talk) 13:39, 4 March 2016 (UTC)
ID for entity pages at Deutsche Digitale Bibliothek
Description | The 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. |
---|---|
Represents | Integrated Authority File (Q36578) |
Data type | External identifier |
Domain | Any 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] |
Example | Johann Wolfgang von Goethe (Q5879) → 118540238 |
Source | External Reference |
Formatter URL | https://www.deutsche-digitale-bibliothek.de/entity/$1 |
Robot and gadget jobs | Could 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 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 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
Description | Property for alcoholic beverages and whether they are vegan or not |
---|---|
Data type | External identifier |
Domain | alcohol brands |
Allowed values | 0-9, a-z |
Example | Absolut Vodka (Q332378) → 5574-absolut-vodka |
Source | https://en.wikipedia.org/wiki/Category:Vegetarianism_and_drinks |
Formatter URL | http://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
Description | The 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 type | String |
Template parameter | none |
Domain | people, organizations, places, descriptors |
Allowed values | string with a mandatory qualifier which is one of "nytd_geo", "nytd_per", "nytd_org", "nytd_des" |
Example | Barack Obama (Q76) → "Obama, Barack" with a qualifier of "nytd_per" |
Format and edit filter validation | qualifier must be one of "nytd_geo", "nytd_per", "nytd_org", "nytd_des" |
Source | external reference, Wikipedia list article, etc. |
Robot and gadget jobs | Many 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)
- @Thinkcontext, Pigsonthewing: what is the status of this? Thryduulf (talk: local | en.wp | en.wikt) 13:56, 23 January 2016 (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)
- 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 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)
- 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 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
Description | identifier assigned to a work of art by the J. Paul Getty Museum |
---|---|
Data type | External identifier |
Domain | works of art |
Allowed values | \d+ |
Example | Rembrandt Laughing (Q20178648) → 263156 |
Source | http://www.getty.edu/art/collection/ |
Formatter URL | http://www.getty.edu/art/collection/objects/$1 |
Robot and gadget jobs | Add 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
Description | for administrative regions of France |
---|---|
Data type | Item |
Template parameter | |subdivision_name1= in en:Template:Infobox settlement |
Example | Saône-et-Loire (Q12736) => Bourgogne-Franche-Comté (Q18578267) |
Robot and gadget jobs | See 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
- Comment Isn't this located in the administrative territorial entity (P131)? Also, what do you mean by "item id for Saône-et-Loire"? Saône-et-Loire (Q12736)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 7 January 2016 (UTC)
- Thanks for the response. Yes I meant Saône-et-Loire (Q12736). Not sure why I did not find it in search. Anyway maybe that is what should be used instead of making a new property. Was confused because of the country property. Made me assume you need for example a US state property or a US country property. But using the generic one seems to make more sense than adding all these specific ones that will be different for every country. Not sure how to use this to meet my end goal though. It seems to be easy to use located in the administrative territorial entity (P131) to fill in the region in the info box for the article for Saône-et-Loire (Q12736). But I am not sure how you could get wikipedia to follow the recursive hierarchy to fill in the region for say Alpuech (Q931649). You could fill in its Caton(the next level up in the administrative hierarchy using located in the administrative territorial entity (P131). And you can fill in the country using the country property. But no idea how you would be able to get the region into its wikipedia article other than by adding a region property or updating wikipedia’s code. Let me know if I should just remove this request if it does not make sense to try do this. Lonjers (talk) 21:37, 7 January 2016 (UTC)
- I think others are working on the hierarchy-of-administrative regions issue, so let's wait for more comments. I've fixed the example, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 9 January 2016 (UTC)
- Cool yea it seems like a bod idea to add this property to me now though. The better solution would be support for traversing the wikidata hierarchy on wikipedia. Would love to work on this though if you could point me in the right direction. Lonjers (talk) 21:19, 13 January 2016 (UTC)
- I think others are working on the hierarchy-of-administrative regions issue, so let's wait for more comments. I've fixed the example, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 9 January 2016 (UTC)
- Thanks for the response. Yes I meant Saône-et-Loire (Q12736). Not sure why I did not find it in search. Anyway maybe that is what should be used instead of making a new property. Was confused because of the country property. Made me assume you need for example a US state property or a US country property. But using the generic one seems to make more sense than adding all these specific ones that will be different for every country. Not sure how to use this to meet my end goal though. It seems to be easy to use located in the administrative territorial entity (P131) to fill in the region in the info box for the article for Saône-et-Loire (Q12736). But I am not sure how you could get wikipedia to follow the recursive hierarchy to fill in the region for say Alpuech (Q931649). You could fill in its Caton(the next level up in the administrative hierarchy using located in the administrative territorial entity (P131). And you can fill in the country using the country property. But no idea how you would be able to get the region into its wikipedia article other than by adding a region property or updating wikipedia’s code. Let me know if I should just remove this request if it does not make sense to try do this. Lonjers (talk) 21:37, 7 January 2016 (UTC)
- Oppose Use located in the administrative territorial entity (P131): ⟨ Saône-et-Loire (Q12736) ⟩ located in the administrative territorial entity (P131) ⟨ Bourgogne-Franche-Comté (Q18578267) ⟩. While establishing the region for an entity such as Alpuech (Q931649) does require a chain of queries to follow until one gets to region, the alternative of listing every step in hierarchy for every entity would require hundreds of properties and a massive increase in the number of statements that would have to be added and maintained. Josh Baumgartner (talk) 17:20, 11 January 2016 (UTC)
Not done Lack of support.--Micru (talk) 13:58, 4 March 2016 (UTC)
version
Description | Version of a work such as records, plays, books |
---|---|
Data type | string, number-invalid datatype (not in Module:i18n/datatype) |
Domain | references |
Example | tumor protein p53 (Q283350) UniProt protein ID (P352) "04637" → "237" |
Source | external 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
Represents | Baltisches biografisches Lexikon digital (Q18616550) |
---|---|
Data type | External identifier |
Domain | human (Q5) |
Example | Felix Eduard Wreden (Q15065137) → Wreden-Felix-Eduard-1841-1878 |
Source | http://www.bbl-digital.de/ |
Formatter URL | http://www.bbl-digital.de/eintrag/$1/ |
Robot and gadget jobs | My 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
Description | the language's phonology includes this sound |
---|---|
Data type | Item |
Domain | language (Q34770) |
Allowed values | |
Example | English (Q1860) → voiced bilabial nasal (Q201817), voiceless dental fricative (Q332019), voiceless velar stop (Q463543), ... (22 others) |
Robot and gadget jobs | This 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, aspect, or form (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":
- "secondary articulation" => labialized consonant (Q19773274)
- 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)
- I would say yes. Popcorndude (talk) 22:51, 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)
- statement disputed by (P1310)? Popcorndude (talk) 20:37, 17 August 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)
- 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)
- 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)
- 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)
- 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
Description | entry in the Dictionary of National Biography |
---|---|
Data type | Item |
Domain | people primarily |
Allowed values | items for DNB entries at Wikisource |
Example | Edward of Norwich, 2nd Duke of York (Q452639) → ‘Plantagenet,’ Edward (Q19019224) |
Source | items with described by source (P1343) and such entries |
Robot and gadget jobs | KrBot 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)
- 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)
- @Pasleim:: in 6 months, such a
- 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.
- 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 …"
- 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)
- @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)
- 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)
- I'm not principally opposing a dedicated property, but my proposal would be:
- ⟨ Edward of Norwich, 2nd Duke of York (Q452639) ⟩ described by source (P1343) ⟨ Dictionary of National Biography, 1885–1900 (Q15987216) ⟩
volume (P478) ⟨ "45" ⟩
section, verse, paragraph, or clause (P958) ⟨ ‘Plantagenet,’ Edward ⟩
reference item Search ⟨ Q19019224 ⟩ - 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 ⟨ subject ⟩ reference URL (P854) ⟨ https://archive.org/stream/dictionaryofnati45stepuoft#page/401/ ⟩. -- 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
Description | identifier for a Major League Baseball player assigned by Baseball-Reference.com |
---|---|
Data type | External identifier |
Template parameter | Wikidata property related to sport (Q21818626) |
Example | Mike Trout (Q3090378) → 545361 |
Source | MLB.com |
Formatter URL | http://m.mlb.com/player/$1 |
Robot and gadget jobs | None |
- 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 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)
Description | entity that the subject of this item founded |
---|---|
Data type | Item |
Domain | human (Q5), organization (Q43229) |
Allowed values | organization (Q43229), geographical feature (Q618123), architectural structure (Q811979), website (Q35127) |
Example | Fatima al-Fihri (Q182363) → University of al-Qarawiyyin (Q378014), Ray Hyman (Q432812) → Committee for Skeptical Inquiry (Q1115728), Huguette Marcelle Clark (Q514218) → Andree Clark Bird Refuge (Q4755706) |
Robot and gadget jobs | replace incorrect uses of founded by (P112) with this property |
- Motivation
This is the inverse of founded by (P112) but I've discovered that there are lots of incorrect uses of that property to do exactly this job. I found the first example while looking to improve Fatima al-Fihri (Q182363) and the other two examples were from a very quick look at Wikidata:Database reports/Constraint violations/P112 (see also Property talk:P112 for comments about other constraint violations). Thryduulf (talk: local | en.wp | en.wikt) 11:15, 7 March 2016 (UTC)
- Discussion
- Withdrawn I've just spotted #founder of has already been proposed elsewhere on this page so I'm withdrawing this proposal as a duplicate. Thryduulf (talk: local | en.wp | en.wikt) 11:35, 7 March 2016 (UTC)
Geni.com Profile ID
Description | Identifier for a profile on the Geni.com genealogy website |
---|---|
Represents | Geni.com (Q2621214) |
Data type | External identifier |
Domain | human (Q5) |
Allowed values | string pattern containing [A-Z][a-z][0-9][-][/] |
Example | Elizabeth II (Q9682) → Queen-Elizabeth-II-of-the-United-Kingdom/6000000003075071669 |
Format and edit filter validation | The string contains one [/]. All characters before the [/] are [A-Z][a-z][0-9][-], and all characters after the string are [0-9]. No limit on length. |
Source | Geni.com website |
Formatter URL | http://www.geni.com/people/$1 |
Robot and gadget jobs | Not required, but Geni does have an API which can be used to cross-check data such as birth date, etc if anyone with the required skills is interested. |
- Motivation
Geni.com is a genealogy website with over 100 million profiles - all connected, including a large number of notable people (who would have Wikipedia/Wikidata entries). The website can calculate relationships between any two people on the tree (examples: 1 2 3 4), although this is limited to paid members so may not be directly useful to Wikidata at this point in time. For sample profile URLs, check the current trending names on Geni. Disclosure, I am a paid member of Geni, but have no other affiliation.
This is my first proposal for a new property, please be gentle! -- Chuq (talk) 11:57, 22 February 2016 (UTC)
- Discussion
- Support It is also on my list to suggest. It has a good landing page and you can add documents and images. If you can link yourself back 5 generations in Europe into the forest (the name for merged genealogy trees) you can see how your are related to just about anyone of European ancestry. As duplicate records get merged Geni keeps a redirect. --Richard Arthur Norton (1958- ) (talk) 23:32, 22 February 2016 (UTC)
- Datatype changed to "External identifier". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 3 March 2016 (UTC)
- Support Very useful. --Edgars2007 (talk) 20:57, 8 March 2016 (UTC)
Done @Chuq, Richard Arthur Norton (1958- ), Pigsonthewing, Edgars2007:--Micru (talk) 21:42, 8 March 2016 (UTC)
superhuman feature or ability
Description | superhuman, supernatural, or paranormal abilities that the subject exhibits |
---|---|
Represents | aptitude (Q1347367) |
Data type | Item |
Template parameter | "powers" in en:template:Infobox comics character and title |
Allowed values | Abilities listed at en:List of superhuman features and abilities in fiction, though not limited to the list |
Example | Scarlet Witch (Q929285) → reality warping (Q21451555) |
Source | List of superhuman features and abilities in fiction |
- Motivation
Would be nice for items about super-characters. You can move this proposal if it's in the wrong place. --AmaryllisGardener talk 01:41, 11 November 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 10:44, 11 November 2015 (UTC)
- Support Mbch331 (talk) 21:34, 11 November 2015 (UTC)
- Support as a broader 'ability' property. I see no reason to limit it to superheroes and their powers, but instead any notable abilities of an entity ought to be able to use this property. Josh Baumgartner (talk) 21:23, 13 November 2015 (UTC)
- If it is notable that an item is capable of reading (Q199657) then I would think so. Josh Baumgartner (talk) 22:53, 13 November 2015 (UTC)
- Yeah, but how would we determine if something is notable or not? Someone could add "ability > reading", "ability > speaking", "ability > walking" and so on to all person items ... what would we do about it? Revert those edits? Jonathan Groß (talk) 12:33, 17 November 2015 (UTC)
- Fictional characters only, That's how you solve that problem. Also, perhaps make an item called something like "superhuman ability", then set up a constraint, and there you go. --AmaryllisGardener talk 19:33, 24 November 2015 (UTC)
- You do not see such kind of information in regular Wikipedia articles. I see no reason to worry that Wikidata would be any differnt. That means the notability test can be exactly the same as for Wikipedia. --Flukas (talk) 16:09, 23 February 2016 (UTC)
- Oppose Fancruft--Kopiersperre (talk) 13:02, 14 November 2015 (UTC)
- Support, but only in the narrow confines of superheroes; re-labelled as "superpower" or suchlike. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:06, 19 November 2015 (UTC)
- It should be restricted to fictional entities regardless. I think I also agree with Kopiersperre. --Izno (talk) 15:54, 7 January 2016 (UTC)
- Support even in the broader sense. --Flukas (talk) 22:09, 22 February 2016 (UTC)
- Support Thierry Caro (talk) 11:05, 27 February 2016 (UTC)
Done @AmaryllisGardener, Joshbaumgartner, Jonathan Groß, Flukas, Kopiersperre, Thierry Caro:@Mbch331, Pigsonthewing, Izno:--Micru (talk) 18:09, 27 February 2016 (UTC)
National-Football-Teams.com player id
Description | player id at National-Football-Teams.com |
---|---|
Data type | External identifier |
Template parameter | pid in en:template:NFT_player |
Domain | human |
Allowed values | numerical value |
Example | David Beckham (Q10520) → 2189 |
Source | the website or wikipedia templates |
Formatter URL | http://www.national-football-teams.com/player/$1.html |
Robot and gadget jobs | bots could be created to import from templates |
- Motivation
National Football Teams (http://www.national-football-teams.com/) seems to be a useful resource for information about domestic and international football (soccer). There are templates that use the website on various language wikipedias, and at least the english template is widely used (18263 transclusions) Silverfish (talk) 23:41, 22 November 2015 (UTC)
- Discussion
- Comment Suggest labelling as, say, "National-Football-Teams.com ID", to avoid ambiguity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:05, 24 November 2015 (UTC)
- That seems sensible. I've made it player id, as there might be other ids we could use from the website. Silverfish (talk) 23:22, 24 November 2015 (UTC)
- Even better. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 9 December 2015 (UTC)
- I withdraw my proposal in favour of this one for the same database as I think it is a better proposal: Wikidata:Property_proposal/Authority_control#National-Football-Teams.com_player_id Silverfish (talk) 23:48, 19 February 2016 (UTC)
- Even better. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 9 December 2015 (UTC)
- That seems sensible. I've made it player id, as there might be other ids we could use from the website. Silverfish (talk) 23:22, 24 November 2015 (UTC)
Batting style
Description | whether a cricketer bats left or right handed |
---|---|
Data type | Item |
Template parameter | "batting" in en:template:Infobox cricketer |
Domain | cricketers (occupation (P106):cricketer (Q12299841)) |
Allowed values | right-handedness (Q3039938), left-handedness (Q789447) |
Example | Phillip Hughes (Q3381076) → left-handedness (Q789447), Ian Botham (Q982121) → right-handedness (Q3039938) |
Source | external reference, Wikipedia list article, etc. |
Robot and gadget jobs | import from en.wp infoboxes |
- Motivation
This is a defining feature for cricketers. See also shooting handedness (P423) and playing hand (P741) for other sports and handedness (P552) generally (which is usually but no necessarily the same as batting style). Thryduulf (talk: local | en.wp | en.wikt) 15:32, 10 November 2015 (UTC)
- Discussion
- I suggest to merge shooting handedness (P423) and playing hand (P741) and define it as a general property of handedness in sports. --Pasleim (talk) 09:15, 11 November 2015 (UTC)
- Merge and use the existing items, per Pasleim. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:10, 13 November 2015 (UTC)
Two issues with the above comments
- Maybe it is more the time for those who have created the properties to assist in their redefinition. If one looks at the talk page for the proposed property to change it is very specific in the components that apply. For a general user to go and to modify this could be problematic, and such a change needs some level of imprimatur or governing and declared process. Someone clueless making that redefinition is simply going to be problematic.
- What is the cricketer bats right-handed, and plays tennis left-handed. It is quite well-known for even professional cricketers to bat one side, and bowl the other (eg. Michael Clarke) so without some delicate redesigning of the property, the simple statement of merge is a simple fail. — billinghurst sDrewth 04:03, 15 November 2015 (UTC)
- Use qualifier to define how the value is applied. Snipre (talk) 09:39, 4 December 2015 (UTC)
- Oppose Snipre (talk) 09:39, 4 December 2015 (UTC)
Not done Recommended to use other properties/qualifier.--Micru (talk) 21:51, 8 March 2016 (UTC)
team caps for local leagues
Description | A number of appearances of player for every team he played with at local leauges. |
---|---|
Data type | Number (not available yet) |
Template parameter | en:template:Infobox football biography caps |
Domain | person |
Allowed values | 0-1000 |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | External reference, Wikipedia list article |
Robot and gadget jobs | they should be allowed |
Proposed by | Xaris333 (talk) 01:26, 3 May 2013 (UTC) |
I am concerned about the name of this property. Different Wikipedia have different methods of choosing which matches do and don't go in the infobox, and I am take-my-car-if-I'm-wrong confident that we will not get a uniform consensus. Some Wikipedia go for the regular season of the league only, others for league + playoffs, others for league + playoffs + cups, and there are a couple of other deviations from these main categories. If we don't name this precisely enough, we will create a mess – English/German/French/Italian speaking editors would probably end up doing different things with the same parameter, and end users at individual wikis would have to painstakingly trawl through the values to work out which one is suitable for their wiki's purposes. I would suggest different properties for league and cup competitions, potentially one more for playoffs, plus one for total appearances. It may seem like overkill, but those three/four parameters would cover almost every conceivable use for this data. —WFC— 07:21, 3 May 2013 (UTC)
- I change the name. Team caps for local leagues. Let see if this could be done, and then we could propose for cups, international legues etc. Xaris333 (talk) 12:17, 3 May 2013 (UTC)
- Bonsoir, excuse me but i'm best in french :) Le problème est que chaque wikipedia fonctionne différement, les francophones comptent championnat + coupes dans l'infobox, les anglophones seulement le championnat, le problème vient également des sources, des sites ont parfois des divergences notamment pour les joueurs du passé, même chose pour les clubs : la différence entre club professionnel et amateur est faite dans les infobox joueurs dans fr.wikipedia pas dans en.wikipedia, les équipes B ne sont également pas indiquées sur fr. wki (sauf pour les pays où le club B est une filiale, exemple l'Espagne)--Remy34 (talk) 19:21, 5 May 2013 (UTC)
- Ok. What do you suggest? We can and must find a global solution what we want to have on wikidata about team caps and goals. It would be really helpfull for users all over the world. Xaris333 (talk) 20:10, 5 May 2013 (UTC)
- Je n'ai pas de suggestion ni d'idée, s'il existait un organisme central des statistiques de footballeur ce serait beaucoup plus simple...--Remy34 (talk) 07:38, 6 May 2013 (UTC)
- une suggestion si recenser les sources statistiques de qualité pour remplir les données concernat les matchs - buts en championnat et dans les autres compétitions (coupes, play offs)--Remy34 (talk) 21:37, 7 May 2013 (UTC)
- Ok. What do you suggest? We can and must find a global solution what we want to have on wikidata about team caps and goals. It would be really helpfull for users all over the world. Xaris333 (talk) 20:10, 5 May 2013 (UTC)
- Bonsoir, excuse me but i'm best in french :) Le problème est que chaque wikipedia fonctionne différement, les francophones comptent championnat + coupes dans l'infobox, les anglophones seulement le championnat, le problème vient également des sources, des sites ont parfois des divergences notamment pour les joueurs du passé, même chose pour les clubs : la différence entre club professionnel et amateur est faite dans les infobox joueurs dans fr.wikipedia pas dans en.wikipedia, les équipes B ne sont également pas indiquées sur fr. wki (sauf pour les pays où le club B est une filiale, exemple l'Espagne)--Remy34 (talk) 19:21, 5 May 2013 (UTC)
Oppose Why a property so specific ? In my opinion, it would be more appropriate to have a property "Total matches played" that could be used as a qualifier of the property member of sports team (P54) but also as a qualifier of a new property "takes part in" when the value is a sport competition. With this structure, the "Total league caps" property is no longer needed and the syntax is simplified. Same goes for the "Team goals for local leagues" and "Total leagues goals" properties : a "Total points scored" property should do the trick and could also be used for other sports than only hockey, football, handball and water-polo. Casper Tinan (talk) 14:21, 8 February 2014 (UTC)
- Brought out from 'pending' for discussion. Josh Baumgartner (talk) 19:39, 18 November 2015 (UTC)
- Oppose number of matches played/races/starts (P1350) already exists and should be sufficient. Josh Baumgartner (talk) 19:39, 18 November 2015 (UTC)
team goals for local leagues
Description | A number of goals of player for every team he played with at local leauges. |
---|---|
Data type | Number (not available yet) |
Template parameter | en:template:Infobox football biography goals |
Domain | person |
Allowed values | 0-300 |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | External reference, Wikipedia list article |
Robot and gadget jobs | they should be allowed |
Proposed by | Xaris333 (talk) 01:26, 3 May 2013 (UTC) |
My comments at team caps apply equally here. —WFC— 07:22, 3 May 2013 (UTC)
- Same for me. My comments at team caps also apply here. Casper Tinan (talk) 14:22, 8 February 2014 (UTC)
- Sorted from Wikidata:Property_proposal/Pending/1 for discussion. Josh Baumgartner (talk) 19:43, 18 November 2015 (UTC)
- Oppose Use number of points/goals/set scored (P1351) instead. Josh Baumgartner (talk) 19:43, 18 November 2015 (UTC)
total leagues caps
Description | The sum of the appearances of player for all the teams he played with (for former player, for local leauges). |
---|---|
Data type | Number (not available yet) |
Template parameter | en:template:Infobox football biography totalcaps |
Domain | person |
Allowed values | 0-1000 |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | External reference, Wikipedia list article |
Robot and gadget jobs | they should be allowed |
Proposed by | Xaris333 (talk) 01:26, 3 May 2013 (UTC) |
- Oppose See my comments about "Team caps".--Casper Tinan (talk) 14:23, 8 February 2014 (UTC)
- Sorted from Wikidata:Property_proposal/Pending/1 for discussion.
- Oppose Use number of matches played/races/starts (P1350) instead. Josh Baumgartner (talk) 19:46, 18 November 2015 (UTC)
total leagues goals
Description | The sum of the goals of player for all the teams he played with (for former player, for local leauges). |
---|---|
Data type | Number (not available yet) |
Template parameter | en:template:Infobox football biography totalgoals |
Domain | person |
Allowed values | 0-1000 |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | External reference, Wikipedia list article |
Robot and gadget jobs | they should be allowed |
Proposed by | Xaris333 (talk) 01:26, 3 May 2013 (UTC) |
My comments at team caps apply to a certain extent here, in the sense that if we have multiple parameters for appearances, there would be multiple relevant totals. —WFC— 07:25, 3 May 2013 (UTC)
- Oppose See my comments about "Team caps".--Casper Tinan (talk) 14:24, 8 February 2014 (UTC)
- Sorted from Wikidata:Property_proposal/Pending/1 for discussion.
- Oppose Use number of points/goals/set scored (P1351) instead. Josh Baumgartner (talk) 19:49, 18 November 2015 (UTC)
first name identical to this family name
Description | given first name that is the same as a last name. Use on items for last names. |
---|---|
Data type | Item |
Domain | surnames/family names |
Allowed values | items for given first names |
Example | Sylvain (Q18001608) (family name): Sylvain (Q16281827) (given name) |
Robot and gadget jobs | Checking and correcting the "inverse of" relation with family name identical to this given name (P1533) |
- Motivation
As an inverse of family name identical to this given name (P1533) to make it easier navigation between both of them. Actually when a surname is added as a given name it can be hard finding which element should be connected there instead, when it is easy to find it in the other way. Agabi10 (talk) 12:14, 11 October 2015 (UTC)
- Discussion
- Support for symmetry: if you like having it ;). To avoid having them mixed up or merged, P1533 is generally sufficient. --- Jura 13:18, 18 October 2015 (UTC)
- Oppose as creating inverse properties for their own sake bloats the database, makes items take longer to load and increases workload on contributors. Ideally, WD will eventually have support for true inverse properties which don't need to be individually entered and maintained, but instead automatically mirror to facilitate navigation within WD. I doubt that is coming any time soon, but creating a bunch of inverse properties just to facilitate navigation within WD is not a good plan. They are sometimes warranted, but in this case, I would have to say that family name identical to this given name (P1533) is sufficient. Note also that if there is both a family name and a given name that are the same, they should both be instances of a general name item that covers all applications of the name and this will give you a way to click-navigate from one to the other. Josh Baumgartner (talk) 23:40, 6 November 2015 (UTC)
- Sorted to person from unsorted. Josh Baumgartner (talk) 23:41, 6 November 2015 (UTC)
- Question Josh Baumgartner I think that I don't understand what you mean. Even if in the future the software mirrors the symmetric properties still two properties will be required to know which property has to be mirrored with each of them (or a way to have more than one name in each property and choose the correct one, or even a renaming of properties to "name-surname relation" to make sense in both of the elements). Also I don't understand how family name identical to this given name (P1533) can be sufficient if the one I know is the surname and I don't know if a name element exists. Also having one element that combines the names and surnames spelled in the same way as you suggest to make it easier the navigation wouldn't bloat the database more than creating one property for that? As far as I know an element and a property are both one row in the database, and while the same property can be used in more than one element a new element will be needed for each couple. -- Agabi10 (talk) 21:07, 7 November 2015 (UTC)
- @Joshbaumgartner: Still waiting an answer to my question. -- Agabi10 (talk) 17:33, 15 November 2015 (UTC)
- @Agabi10: Regardless of whether or not such a technical development ever happens, I oppose this property as unnecessary bloat. In fact, I don't even see a purpose for family name identical to this given name (P1533) in a structured database, much less a needless reflection of it. However, it is there and if the structure of given and family names being subsets of a general name item isn't handy for you and you have to put a direct link between the two, then family name identical to this given name (P1533) would do it. There is no need to have to enter that information on both family and given name items. I'm not sure I understand your question about knowing the surname but not the other, since even with your proposal, you would have to know both family and given name to be able to create the statement, and if you know both then why not use family name identical to this given name (P1533)? Josh Baumgartner (talk) 01:16, 18 November 2015 (UTC)
- @Joshbaumgartner: I agree with you in the reasoning that this property and family name identical to this given name (P1533) would be completely useless, but only in a state of the database where there is no type constraint violations in where a surname was used as a value for the name property or in the other way. I know that the people who adds the properties to any of the name/surname elements (even if it is me or any other) will have to know, at least for a moment, that there is an element created for the other one to be able to put the property. The thing is that if after them someone tries to correct constraint violations related to elements with that property where the incorrect one is put they will find it easier.
I also know that the ideal solution would be that the suggestion drop down shows first a value with a name instance for a name property, and the same happens with all of the other properties, which, as far as I know at this moment is not necessarily true. This would decrease the number of violations. Having correct names and descriptions for all the entities in all the languages would also help, but that's too idealistic. Being able to search for a value without having to use external tools (even if Magnus' tools are great) would also make it all of this easier to find elements with family name identical to this given name (P1533) with the current element as a value.
As you can see I know that there are more ways to solve it that are also technically possible, but at this specific moment I think that an inverse property is the most feasible one. At least now I understand better why you are opposing and even if the explanation doesn't make you change your mind at least I hope that now both of us are understanding what the other wanted to make clear. – The preceding unsigned comment was added by Agabi10 (talk • contribs).
- Oppose per Josh B. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:16, 18 November 2015 (UTC)
- Oppose first names are commonly used as names, normally not the contrary :/ it would not be logical - and I agree first name and name being subsets of a general name. :) --Hsarrazin (talk) 09:45, 24 December 2015 (UTC)
Not done Lack of support.--Micru (talk) 17:51, 27 February 2016 (UTC)
name
Description | name the subject is known by |
---|---|
Represents | name (Q82799) |
Data type | Monolingual text |
Example | see below |
We currently have several name properties which apply to certain specific types of names. However, sources do not always provide such definition when they provide a name, so there is no way to create a claim for the subject's name and know for sure which property to use. An educated guess constitutes a certain amount of original research. A contributor might see 'John Smith' and assume that given name (P735) John and family name (P734) Smith are appropriate, but even as uncontroversial as this may be to a native English speaker, there are many different linguistic constructs for names and many do not conform to first-last format. Even if we do add properties to cover all of the different classes of name out there, we will still have cases where the exact type is unknown, so we need a super-property that covers all of the name properties:
- Sub-properties of name: given name (P735), family name (P734), pseudonym (P742), official name (P1448), birth name (P1477), taxon name (P225), taxon common name (P1843), second family name in Spanish name (P1950) (based on a quick search, but more may be out there and more will be created)
There are various ways in which this property can be used:
- Where the source provides a name and it is not specified what class the name/names fall into.
- "His name was Leo Tolstoy."
- Where the source provides a name and what kind of name it is, but there is not an appropriate property for that type of name.
- "Widely known as Leo Tolstoy, he was born Lev Nikolayevich Tolstoy, son of Nikolai Ilyich Tolstoy."
In an ideal world, all values would eventually be sorted into appropriate sub-categories as sources are found to substantiate such claims. The reality is that much of this type of specific detail is not available for some subjects and therefore the overarching property is needed. Josh Baumgartner (talk) 22:45, 20 October 2015 (UTC)
- Discussion
- Why not just have a different property for each type of name, instead of the P794 (P794) business? There aren't even a dozen of them, I think. --Yair rand (talk) 23:11, 20 October 2015 (UTC)
- @Yair rand: That is what I thought at first, but what do you do when you know it is their name (per your source), but it is not clear what class of name it falls under (because your source does not specify)? You are left to guess, which is not appropriate for a sourced statement. The other problem is that not all name classes have their own properties, and it is possible that the community will deem some of them too specific to warrant their own property. I actually would support a broad set of such properties, but there are cases where the right one does not exist. However, as I noted above, even if they all did, you still need this property to avoid invalid claims based on guessing. Josh Baumgartner (talk) 21:41, 21 October 2015 (UTC)
- So, why the broad usage examples? I could support a property for situations where the name type just isn't known, but if you're specifying anyway, I don't see why this should be used. Also, the monolingual datatype is probably wrong. --Yair rand (talk) 22:02, 26 October 2015 (UTC)
- @Yair rand: I'm not sure I understand your question, I am proposing that this be used in exactly that case: where the name type is not known (see the first example I show). As for monolingual datatype, I'm open as to how to do that better. Is a simple string a better plan? Josh Baumgartner (talk) 16:41, 28 October 2015 (UTC)
- @Joshbaumgartner: In the second example given above, you list "name <Leo Tolstoy>" along with the given name and family name properties. If the given name and family name are already specified, why the extra statement? Or am I reading the example incorrectly?
- Regarding datatype, the properties given name (P735) and family name (P734) both use the item datatype, which allows for more structured data (along with easier handling of multilingual issues, in my opinion). The "name" property would also need to be item datatype for other name properties to be subproperty of (P1647) of it, as suggested by Filceolaire below. --Yair rand (talk) 22:26, 28 October 2015 (UTC)
- @Yair rand: I'm not sure I understand your question, I am proposing that this be used in exactly that case: where the name type is not known (see the first example I show). As for monolingual datatype, I'm open as to how to do that better. Is a simple string a better plan? Josh Baumgartner (talk) 16:41, 28 October 2015 (UTC)
- So, why the broad usage examples? I could support a property for situations where the name type just isn't known, but if you're specifying anyway, I don't see why this should be used. Also, the monolingual datatype is probably wrong. --Yair rand (talk) 22:02, 26 October 2015 (UTC)
- @Yair rand: That is what I thought at first, but what do you do when you know it is their name (per your source), but it is not clear what class of name it falls under (because your source does not specify)? You are left to guess, which is not appropriate for a sourced statement. The other problem is that not all name classes have their own properties, and it is possible that the community will deem some of them too specific to warrant their own property. I actually would support a broad set of such properties, but there are cases where the right one does not exist. However, as I noted above, even if they all did, you still need this property to avoid invalid claims based on guessing. Josh Baumgartner (talk) 21:41, 21 October 2015 (UTC)
- @Yair rand: Maybe the model of my second example won't prove to be how this is used, but even if that proves true, use for the first case is sufficient to warrant creation of this property. Also, details of how we apply subproperty of (P1647) is a discussion that does not necessarily relate to whether or not we should have the property. Making the datatype 'item' would be a huge burden to create an item for every permutation of a full name that might be cited. Josh Baumgartner (talk) 19:19, 18 November 2015 (UTC)
- I don't think I understand the scope of the property. Are the examples above actual statements that would be added? If not, would the item Leo Tolstoy (Q7243) use this property at all? If so, what statements would there be? Could you give some more examples? --Yair rand (talk) 21:22, 2 December 2015 (UTC)
- @Yair rand: Maybe the model of my second example won't prove to be how this is used, but even if that proves true, use for the first case is sufficient to warrant creation of this property. Also, details of how we apply subproperty of (P1647) is a discussion that does not necessarily relate to whether or not we should have the property. Making the datatype 'item' would be a huge burden to create an item for every permutation of a full name that might be cited. Josh Baumgartner (talk) 19:19, 18 November 2015 (UTC)
- Strong Support. We need this as a property for other names to be subproperty of (P1647) of to use with a "search including subproperties" function - when we finally get one. We need it so that when we specify two given names, three family names, a patronymic (property needed for this) we can show how all these are put together - sometimes birth name isn't right for this. Joe Filceolaire (talk) 22:21, 25 October 2015 (UTC)
- Support - Per Joe's comment immediately above. Can we add married name to the list, too? Dirtlawyer1 (talk) 06:17, 14 November 2015 (UTC)
- Support per Joe Filceolaire. Need a generic property where other could be subproperty of (P1647), including Jean Racine (Q742). --Hsarrazin (talk) 09:53, 24 December 2015 (UTC)
- Support easy to use. --La femme de menage (talk) 17:33, 23 January 2016 (UTC)
- Support. Essential. Thryduulf (talk: local | en.wp | en.wikt) 00:21, 25 January 2016 (UTC)
Done @Joshbaumgartner, Yair rand, Dirtlawyer1, Hsarrazin, La femme de menage, Thryduulf:--Micru (talk) 17:40, 27 February 2016 (UTC)
- @La femme de menage: Tu sais qui a traduit "name" en français ? "nom" en générique ça ne m'a pas l'air de correspondre au fait que toutes les propriétés de nommage deviennent des sous-propriété, ça voudrait dire que le nom de famille est un nom d'usage, ça collerait ? author TomT0m / talk page 18:25, 1 March 2016 (UTC)
- @Joshbaumgartner, Micru, Filceolaire, Thryduulf, Yair rand, Hsarrazin: I can see a problem here : the claim that given name is a subproperty of this property : it can't be a subproperty because of a datatype mismatch. It's expected for a subproperty to be of the same dataype than its parent properties, and item datatype is very much not a monolingual type. author TomT0m / talk page 18:25, 1 March 2016 (UTC)
married name
Description | married name |
---|---|
Data type | Monolingual text |
Template parameter | various, often not distinguished from "full name" |
Domain | persons |
Allowed values | text |
Example | Hillary Clinton (Q6294) -> Hillary Clinton; Hillary Rodham Clinton; Hillary Rodham-Clinton; Svetlana Andropovna; Maria Garcia de Vega (full married names, per reliable sources) |
Source | external reference, Wikipedia article |
- Motivation
We already have the property "family name," but this does not distinguish between a woman's family name at birth and her later married name(s). We should have the ability to distinguish between the two. At present we can only enter married names in the "family name" property without explanation or distinction, or the "also known as" alias field also without explanation or distinction. Dirtlawyer1 (talk) 08:35, 19 October 2015 (UTC)
- Discussion
This is the first time I have made such a request, and I am not familiar with all of the requested information items above. If you have questions, please ask. Please be patient with this rookie. Thanks. Dirtlawyer1 (talk) 08:35, 19 October 2015 (UTC)
- Why not just use family name (P734) with a start time (P580) qualifier? --Yair rand (talk) 20:59, 19 October 2015 (UTC)
- This works only if you know the wedding day. --Pasleim (talk) 21:18, 19 October 2015 (UTC)
- Or year, or any other vague span of time in which the name change may have happened. And if it's completely unknown, one should probably put start date: unknown anyway. --Yair rand (talk) 23:25, 19 October 2015 (UTC)
- "family name" has datatype 'item' - it links to a surname item. The "married name" property proposed here is like birth name (P1477) in that the actual name is spelled out. This can still have family name (P734) as a qualifier. Joe Filceolaire (talk) 01:08, 9 December 2015 (UTC)
- Or year, or any other vague span of time in which the name change may have happened. And if it's completely unknown, one should probably put start date: unknown anyway. --Yair rand (talk) 23:25, 19 October 2015 (UTC)
- This works only if you know the wedding day. --Pasleim (talk) 21:18, 19 October 2015 (UTC)
- Comment just to clarify (as there is no sample), for Q6294 would this read "Clinton" or "Hillary Clinton"? --- Jura 07:07, 20 October 2015 (UTC)
- @Jura1: Well, sir, that's subject to negotiation, but I would suggest that the new property structure should parallel that of the existing "birth name" property, and be a complete name with the language specified. Married names often vary widely in structure, with the relatively simple taking of the husband's surname (e.g., Hillary Clinton), the creation of a compound name (e.g., Hillary Rodham-Clinton), the use of both husband surname and the wife's maiden surname as a middle name without hyphen (e.g., Hillary Rodham Clinton), a different feminine surname form in Russian and several other Slavic languages (e.g., Svetlana Andropovna), or Spanish married combined name forms (Hillary Rodham de Clinton). I'm sure there are numerous other cultural and linguistic variations with which I am unfamiliar, combined with what is often the complete choice of the parties in the relatively new scenario of same-sex marriages. I know that in several countries, such as Germany, the format of married names has been strictly regulated by law, while in most English-speaking countries, the only limitations are social customs, which have been evolving toward greater flexibility and variation since the 1960s. Dirtlawyer1 (talk) 13:08, 20 October 2015 (UTC)
- Comment yet one more naming property ? It's already complicate to choose a property in the list. I Oppose. Use "begin date" / "end date" on the (approximate) mariage date and preferred rank on the name valid ATM. Let's use Wikidata data model powerfulness ! author TomT0m / talk page 17:46, 20 October 2015 (UTC)
- @TomT0m: I appreciate your opinion, but it ignores the simple fact that for the overwhelming majority of our subjects with married names, we have neither an exact date nor even a year of their marriage. Of course, the situation is even more complicated for persons who have been married more than once. We need a property that identifies and collects all married names of a subject person within a single property, and that provides the flexibility to address the multiple married name formats not only in English-speaking countries, but multiple countries and cultures around the world. Stuffing married names into the "family name" property -- which only permits the entry of single-word linked family names -- does not do that. Please see my comment @Jura1 above regarding examples of the multiple formats of married names around the globe; the "family name" property simply is not made to purpose. Thanks. Dirtlawyer1 (talk) 19:08, 20 October 2015 (UTC)
- @Dirtlawyer1: "the "family name" property simply is not made to purpose" => See the study about names on the talkpage of WikiProject Name for the different naming schemes in the world. This IS NOT a problem about married names, this is about all naming scheme. A scecialized property for married named won't help at all. I don't see how such a property will help if there is no known date either. It's exactly the same problem. It's enough to put the last known name with the "preferred" rank, and to use end date qualifiers and maybe qualifier about the order in sequence if we have no name. author TomT0m / talk page 19:15, 20 October 2015 (UTC)
- @TomT0m: I appreciate your opinion, but it ignores the simple fact that for the overwhelming majority of our subjects with married names, we have neither an exact date nor even a year of their marriage. Of course, the situation is even more complicated for persons who have been married more than once. We need a property that identifies and collects all married names of a subject person within a single property, and that provides the flexibility to address the multiple married name formats not only in English-speaking countries, but multiple countries and cultures around the world. Stuffing married names into the "family name" property -- which only permits the entry of single-word linked family names -- does not do that. Please see my comment @Jura1 above regarding examples of the multiple formats of married names around the globe; the "family name" property simply is not made to purpose. Thanks. Dirtlawyer1 (talk) 19:08, 20 October 2015 (UTC)
- Support The advantage of having "married name" as a simple string parallel to birth name (P1477) is that this is very easy to extract and use (and very easy to understand). Any scheme that involves qualifiers immediately is made a lot harder to query -- even more so if one would then have to filter out any other reasons why a name might have been changed. In contrast with two simple properties for birth-name and married-name, it becomes very easy to see whether one of those fields is missing.<br?>I am not against making sure that the married family-name is also reflected as a value for family name (P734) -- just as the relevant family-name part of a birth name (P1477) would be reflected in that way. Having an explicit property for the full married name as a string, parallel to birth name (P1477), in fact makes it easier to achieve and maintain appropriate values for the family name (P734) property, because it then becomes easy to check that values corresponding to both the birth name (P1477) string and the married-name string are present -- when these two properties are known and distinct, then there ought to be the correspondingly appropriate number of distinct values for family name (P734). Jheald (talk) 19:45, 20 October 2015 (UTC)
- @Jheald: This argument has little to do with "married name" as such, it would hold for the name of the person as well. Plus ... it's a lot worse. A person can be married several time, how would this work ? We would have to create a "second married name" ? This would be a property mess. For this, rename "name at birth" "full name", and use ranks and date, per the same reasoning I used above. author TomT0m / talk page 20:03, 20 October 2015 (UTC)
- @TomT0m: If we were to go down that route, it would make it very difficult to systematically extract birth names for a particular group of people. Having to use comparison operators on qualifier dates for a variety of full name values would kill query performance stone dead.
Yes, there will be cases where there will be more than one married name. But in such cases one will usually want to extract all of them, and one can use an ORDER BY clause. On the other hand, one may well want the original birth name in a separate column, and that would be a total nightmare with the system you suggest. Jheald (talk) 21:20, 20 October 2015 (UTC)- @Jheald: I'm pretty sure it's not harder to do a min or max in SPARQL than to do an order by clause. (plus I'm pretty dubious that it's not really a usecase to extract birth names for a particular group of people. To extract the birth name or someone for its infobox OK, apart from that ... I really hate the proliferation of naming properties we can currently see pop down in the suggest list. You really have to be an expert to choose the right one. author TomT0m / talk page 21:27, 20 October 2015 (UTC)
- PS: It is possible, see http://rdf.myexperiment.org/howtosparql?page=GROUP%20BY for example. author TomT0m / talk page 21:30, 20 October 2015 (UTC)
- The point is that you are then relying on all of the date qualifiers to be in place and to be correct, simply to extract the birth name -- it's a lot more robust simply to have a birth name property, then you don't have to rely on any qualifiers to identify the right value.
Yes, you could introduce an additional sub-query for each individual, to join in all the names and all the date qualifiers into the query, with an ORDER BY and a LIMIT 1 to extract the earliest (if all of the qualifiers are there and correct) -- but it makes a hell of a lot more work; plus you would probably have to hand-optimise it, because the auto-optimiser is a bit random when it comes to queries involving sub-queries. (A sub-query is needed rather than GROUP BY because one can extract the earliest date with GROUP BY and MIN(), but there's no obvious way to get the name that goes with it).
Finally, I don't think it is unrealistic for users to potentially want a list of individuals that included a column of birth-names and a separate column of married names. Particularly for a print-out, that is very often exactly the format one wants. (Something like thistinyurl.com/nwwk6ny
, though at the moment we're a bit short of data). Jheald (talk) 22:07, 20 October 2015 (UTC)
- The point is that you are then relying on all of the date qualifiers to be in place and to be correct, simply to extract the birth name -- it's a lot more robust simply to have a birth name property, then you don't have to rely on any qualifiers to identify the right value.
- @TomT0m: If we were to go down that route, it would make it very difficult to systematically extract birth names for a particular group of people. Having to use comparison operators on qualifier dates for a variety of full name values would kill query performance stone dead.
- @Jheald: This argument has little to do with "married name" as such, it would hold for the name of the person as well. Plus ... it's a lot worse. A person can be married several time, how would this work ? We would have to create a "second married name" ? This would be a property mess. For this, rename "name at birth" "full name", and use ranks and date, per the same reasoning I used above. author TomT0m / talk page 20:03, 20 October 2015 (UTC)
- A further thought: it may make most sense to introduce the "married name" property as a qualifier to spouse (P26). This would be the way to most directly associate the property with the right dates (if available) and the right spouse. Jheald (talk) 22:35, 20 October 2015 (UTC)
- @Jheald: Good thought, but that only works if (a) we know at least the common, if not full name of the spouse, and (b) the spouse field may be entered as a plain text string (not linked text) for non-notable spouses. Dirtlawyer1 (talk) 18:38, 21 October 2015 (UTC)
- Not sure how this would work for Molly Meacher (Q1943636) or Angela Merkel (Q567). --- Jura 13:03, 26 October 2015 (UTC)
- @Jura1: I will let Jheald speak for himself, but I believe that Angela Merkel's legal married name is "Angela Dorothea Merkel," in keeping with the German name laws. When Merkel divorced her first husband she kept the Merkel name, and did not take her second husband's name when she remarried in 1998 (presumably because she was already well known publicly and politically as "Angela Merkel"). Had Merkel taken her second husband's name, as an example, the proposed property should be able to accommodate additional married names from second and third marriages, etc. Molly Meacher's legal married name is "Molly Christine Meacher," which appears to be relatively straightforward. Dirtlawyer1 (talk) 21:15, 26 October 2015 (UTC)
- Oppose per Yair rand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 23 October 2015 (UTC)
- Strong Support. Saying <family name:Clinton> with a start date doesn't tell us if her married name is Hilary Clinton or Hilary Rodham-Clinton or Hilary Clinton Rodham. We need this property with text datatype to specify the name she uses. 'Family name' can then be a qualifier to 'married name' to show what family names she uses since she is married with a different set of 'family names' as qualifier to her birth name. Joe Filceolaire (talk) 22:28, 25 October 2015 (UTC)
- Support, but it will need to be clarified that it is to be the full name, not just the assumed family name (or we can do it that way and make it 'item' datatype in line with 'family name'). Josh Baumgartner (talk) 01:22, 18 November 2015 (UTC)
- Josh, it is intended that the datatype be text (not a linked item) and that the full married name be used, not just the assumed family name. Because of the various different types and forms of married names -- e.g., husband's family name, compound-hyphenated name, feminine version of husband's family name, maiden name as middle name + husband's family name, etc. -- the simplest and most accurate way to enter the name in every instance is text format. As it is, we do not have items for every surname. Dirtlawyer1 (talk) 14:05, 18 November 2015 (UTC)
- Maybe "full married name" would be a better label to use to make it clearer. - Nikki (talk) 21:07, 19 February 2016 (UTC)
- Support, Some women can be married up to 10 times, think Bonnie Lee Bakley, and get a new name each time, or they may carry over the surname of the previous husband and hyphenate it with the new husband. --Richard Arthur Norton (1958- ) (talk) 18:44, 19 February 2016 (UTC)
- Support - Brya (talk) 17:27, 27 February 2016 (UTC)
Done @Dirtlawyer1, Yair rand, Pasleim, Jura1, TomT0m, Pigsonthewing:@Joshbaumgartner, Nikki, Richard Arthur Norton (1958- ), Brya, Jheald:--Micru (talk) 17:50, 27 February 2016 (UTC)
Québec cultural heritage directory people identifier
Description | people listed on the Répertoire du patrimoine culturel du Québec |
---|---|
Represents | Répertoire du patrimoine culturel du Québec (Q3456276) |
Data type | External identifier |
Domain | person (Q215627), human (Q5) |
Allowed values | \d{4,5} |
Example | Pierre Gauvreau (Q22342916) → 7545 |
Source | http://www.patrimoine-culturel.gouv.qc.ca/rpcq/rechercheProtege.do?methode=afficher |
Formatter URL | http://www.patrimoine-culturel.gouv.qc.ca/rpcq/detail.do?methode=consulter&id=$1&type=pge |
- Motivation
This property will can be usefull to source a architecte to a house he made, or a historic people to the house he lived. The property url and a the constraint are different of Quebec cultural heritage directory ID (P633). Fralambert (talk) 14:22, 31 January 2016 (UTC)
- Support seems pretty good. By the way, the example page cites biographi.ca which seems good too, I don't think we have any property for it at the moment either. -- – The preceding unsigned comment was added by Zolo (talk • contribs).
- @Zolo:: If i check biographi.ca, it is not realy a ID, but it shoud be fesable to create a string property (ex.: Ludger Duvernay (Q3266045) --> duvernay_ludger_8F) --Fralambert (talk) 16:33, 31 January 2016 (UTC)
National-Football-Teams.com player id
Template parameter | pid in en:template:NFT_player and other language equivalents. |
---|---|
Domain | human (Q5) |
Robot and gadget jobs | My bot can import values from Wikipedias |
- Motivation
One of the last (I think) major football databases, useful for references. Edgars2007 (talk) 14:14, 13 February 2016 (UTC)
- Discussion
I've already suggested it in the Person category (Wikidata:Property_proposal/Person#National-Football-Teams.com_player_id). I'm not sure which section (Authority Control or Person) is better, to be honest. Silverfish (talk) 18:13, 13 February 2016 (UTC)
- Oh, didn't notice it. Well, all those external identifiers have been proposed here. But we could merge these requests. --Edgars2007 (talk) 19:28, 13 February 2016 (UTC)
- I don't know what the procedure would be to merge proposals, but I Support your proposal for this. I'll link to this proposal from my proposal, and withdraw it, as I think this version is probably better. I've change the name to National-Football-Teams.com player id as it's less ambiguious, and added a description and template parameter. Silverfish (talk) 23:20, 19 February 2016 (UTC)
@Edgars2007, Silverfish: Done National-Football-Teams.com player ID (P2574) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 3 March 2016 (UTC)
B2Q Bibliothèque et Archives nationales du Québec (BAnQ) indentity
Description | Authority control for the Bibliothèque et Archives nationales du Québec (BAnQ) |
---|---|
Represents | Bibliothèque et Archives nationales du Québec identifier (Q22916615) |
Data type | External identifier |
Domain | people, documents |
Allowed values | numeric |
Example | 0000050788 → United States Declaration of Independence (Q127912) |
Source | VIAF |
- Motivation
Full property being linked to by VIAF Hazmat2 (talk) 16:54, 22 February 2016 (UTC)
- Discussion
Oppose According to the VIAF partner page the authority file is not online and I have not been able to find anything sensible by the number "0000015804" in the B2Q catalogues. Thus VIAF would be our only source and we neither could verify the number nor do something meaningful with it. -- Gymel (talk) 22:10, 24 February 2016 (UTC)
Not done Per Gymel.--Micru (talk) 14:08, 4 March 2016 (UTC)
Latvian Olympic Committee athlete ID
Domain | human (Q5) |
---|---|
Robot and gadget jobs | My bot can import values from Wikipedias |
- Motivation
Useful source for Olympic athletes from Latvia; used widely in Latvian Wikipedia. Would like to match these entries to Wikidata items. --Edgars2007 (talk) 12:04, 26 February 2016 (UTC)
- Discussion
If somebody wants to say, that this is minor database/property, then I would like to note, that we already have ID for Sweden (Swedish Olympic Committee athlete ID (P2323)). But I understand, that Latvia isn't Sweden ;) --Edgars2007 (talk) 12:20, 26 February 2016 (UTC)
- Support Good external source for this topic. --Papuass (talk) 20:49, 1 March 2016 (UTC)
@Edgars2007, Papuass: Done, see Latvian Olympic Committee athlete ID (archived) (P2593) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:25, 7 March 2016 (UTC)
Code for Indonesian Administrative Division
Description | Unique identification code for administrative division of the Republic of Indonesia |
---|---|
Data type | External identifier |
Domain | settlements in Indonesia |
Allowed values | four numbers separated by decimal point |
Example | Watuagung (Q13098442) → 33.22.06.2008 |
Source | http://www.kemendagri.go.id/pages/data-wilayah |
- Motivation
Volunteers from Wikipedia Indonesia plan to add all list of identifiers, creating new item when necessary. Beeyan (talk) 10:20, 29 February 2016 (UTC)
- Discussion
- Strong support It is needed so we can start Siska.Doviana (talk) 07:20, 1 March 2016 (UTC)
- Strong support ··· 👦 Rachmat04 · 💬 04:06, 2 March 2016 (UTC)
- Strong support Mariyanah
Done @Siska.Doviana, Rachmat04, Mariyanah: --Micru (talk) 14:25, 5 March 2016 (UTC)
Statistics Indonesia ethnicity code
Description | ethnicity code in Indonesia by Statistics Indonesia |
---|---|
Data type | External identifier |
Domain | ethnicity in Indonesia |
Allowed values | five digits, the last digit separated by space |
Example | Javanese (Q49209) → 0114 6 |
Source | http://microdata.bps.go.id/mikrodata/index.php/catalog/SP |
- Motivation
Volunteers from Wikipedia Indonesia plan to add all list of ethnicities from Statistics Indonesia Beeyan (talk) 10:37, 29 February 2016 (UTC)
- Discussion
- Strong support would be interesting to add Siska.Doviana (talk) 07:20, 1 March 2016 (UTC)
- Strong support ··· 👦 Rachmat04 · 💬 04:06, 2 March 2016 (UTC)
- Strong support Mariyanah (talk) 07:47, 3 March 2016 (UTC)
- Comment If it's an external id, we need a formatter URL and the example should contain a full link (and only show the id). Mbch331 (talk) 18:21, 4 March 2016 (UTC)
- Actually, we don't.
--- Jura 07:43, 5 March 2016 (UTC)
- Actually, we don't.
- Hello @Mbch331:, it's PDF file. It doesn't have a formatted URL. --Beeyan (talk) 08:05, 5 March 2016 (UTC)
Done @Siska.Doviana, Rachmat04, Mariyanah: --Micru (talk) 14:25, 5 March 2016 (UTC)
Statistics Indonesia language code
Description | language code in Indonesia by Statistics Indonesia |
---|---|
Data type | External identifier |
Domain | language in Indonesia |
Allowed values | five digits, the last digit separated by space |
Example | Javanese (Q33549) → 0088 3 |
Source | http://microdata.bps.go.id/mikrodata/index.php/catalog/SP |
- Motivation
Volunteers from Wikipedia Indonesia plan to add all list of languages from Statistics Indonesia Beeyan (talk) 10:38, 29 February 2016 (UTC)
- Discussion
- Strong support Yes, it is needed so we can start adding data Siska.Doviana (talk) 07:21, 1 March 2016 (UTC)
- Strong support ··· 👦 Rachmat04 · 💬 04:06, 2 March 2016 (UTC)
- Strong support Mariyanah (talk) 07:48, 3 March 2016 (UTC)
- Comment If it's an external id, we need a formatter URL and the example should contain a full link (and only show the id). Mbch331 (talk) 18:20, 4 March 2016 (UTC)
- Hello @Mbch331:, it's PDF file. It doesn't have a formatted URL. --Beeyan (talk) 08:06, 5 March 2016 (UTC)
Done @Siska.Doviana, Rachmat04, Mariyanah: --Micru (talk) 14:25, 5 March 2016 (UTC)
ASF KID Cave Tag Number
Description | Unique identifier for caves within the Karst Index Database of the Australian Speleological Federation |
---|---|
Represents | cave (Q35509) |
Data type | String |
Template parameter | No parameters known to exist, however a new parameter could be added to en:template:infobox cave |
Domain | cave (Q35509) |
Allowed values | string pattern: ([A-Z]|\d){1-3}\-X?\d+ |
Example | Mammoth Cave (Q10954073) → 6WI-38 |
Source | Karst Index Database of the Australian Speleological Federation |
Robot and gadget jobs | Manual import is most likely |
- Motivation
Most of the information known about caves within Australia is held by numerous caving clubs/societies, with the ASF hosting a database (KID) which aims to collate the knowledge held by clubs into one shared source. The database contains a list of caves known within Australia, as well as detailed data on the characteristics of each cave (length, depth, features, date of discovery, etc). Caves usually have a little metal tag at the entrance stating the cave area code and serial number of the cave within the area. This unique identifier is referred to in literature published by speleological/caving societies, on maps and in books. Dhx1 (talk) 03:59, 22 November 2015 (UTC)
- Discussion
Not done Lack of support.--Micru (talk) 21:59, 9 March 2016 (UTC)
Boundary
Description | Link to a GeoJSON file describing the boundary of the place. |
---|---|
Data type | URL |
Domain | geographical feature (Q618123) |
Allowed values | File should contain a polygon or multipolygon corresponding to the boundaries of the geographical location. |
Example | Boston (Q100) → http://example.org/Boston.json |
Source | Wikimedia Commons |
- Motivation
I want to programmatically get shapes for use in interactive maps such as the one demonstrated in mw:Extension:Graph/Interactive_Graph_Tutorial.
- Discussion
Maybe properties would be more useful than links, so it would be easy to write a single query that fetches a whole group of place boundaries along with another property such as ISO code. – The preceding unsigned comment was added by Ejegg (talk • contribs).
- Oppose using the URL datatype. This should use the GeoShapes datatype when it becomes available. --Yair rand (talk) 22:24, 21 January 2016 (UTC)
Not done --Micru (talk) 14:05, 27 February 2016 (UTC)
- @Micru: Seems a bit early to close as "not done".
--- Jura 19:50, 1 March 2016 (UTC)
- @Jura: The oppose reason seemed quite conclusive to me. Do you have further arguments? I can reopen it if you wish to add something.--Micru (talk) 22:24, 1 March 2016 (UTC)
- If there are such files at Commons, I don't see why we couldn't have some sort of a link to retrieve them. It's not even sure if phab:T57549 is ever to be done.
--- Jura 22:29, 1 March 2016 (UTC)- @Jura1: Can you please tell me where are the json files in Commons? I was unable to find them...--Micru (talk) 10:14, 5 March 2016 (UTC)
- @Micru: It says so in the proposal, let's ask its author @Ejegg:
--- Jura 16:19, 5 March 2016 (UTC)
- @Micru: It says so in the proposal, let's ask its author @Ejegg:
- @Jura1: Can you please tell me where are the json files in Commons? I was unable to find them...--Micru (talk) 10:14, 5 March 2016 (UTC)
- If there are such files at Commons, I don't see why we couldn't have some sort of a link to retrieve them. It's not even sure if phab:T57549 is ever to be done.
- @Jura: The oppose reason seemed quite conclusive to me. Do you have further arguments? I can reopen it if you wish to add something.--Micru (talk) 22:24, 1 March 2016 (UTC)
Number of out of school children
Domain | countries, regions |
---|---|
Source | Initial import from http://data.uis.unesco.org/ UNESCO Institute for Statistics, could include other sources. |
- Motivation
Useful information about the level of education, can be applied to countries, regions etc, initial import of data from the UNESCO Institute for Statistics. This is part of my work as Wikimedian in Residence at UNESCO. John Cummings (talk) 09:29, 3 February 2016 (UTC)
- Discussion
- Comment if you want to import a series of fields, please draw a list, map them to existing characteristics and then propose any missing ones. I don't think we should repeat the NIOSH experience. For identifiers, I'd just go ahead on propose them.
--- Jura 04:46, 4 February 2016 (UTC)
- @Jura1: Can you explain what you mean by 'the NIOSH experience'? John Cummings (talk) 08:51, 4 February 2016 (UTC)
I plan to import some of the data from the UNESCO UIS database starting with the education data.
The plan for this property would be to add claims to countries using the following qualifiers:
- Male or female
- Primary age
- Lower secondary age
- Pre Primary education
- Year with the oldest data would come from 1999 and the most recent is in most cases from 2014
Not all data is available for all countries on all dates John Cummings (talk) 10:30, 15 February 2016 (UTC)
@John Cummings: Done number of out-of-school children (P2573) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 3 March 2016 (UTC)
- @Pigsonthewing:, thanks very much Andy. John Cummings (talk) 15:32, 3 March 2016 (UTC)
Australian Wetlands Database Directory of Important Wetlands Reference Code
Description | Identifier of an important Australian wetland listed in the Australian Wetlands Database Directory of Important Wetlands managed by the Australian Government Department of the Environment |
---|---|
Represents | wetland (Q170321) |
Data type | External identifier |
Template parameter | No existing property is known to exist, and no wetland infobox is known to exist. Perhaps en:template:Designation list could be updated |
Domain | wetland (Q170321) where located in/on physical feature (P706) = Australian continent (Q3960) (approximation only) |
Allowed values | string pattern: (ACT|VIC|NSW|SA|TAS|QLD|WA|NT|EXT)\d+ |
Example | Ginini Flats Wetlands Ramsar Site (Q5563129) → ACT002 |
Source | Australian Wetlands Database » Directory of Important Wetlands |
Formatter URL | http://www.environment.gov.au/cgi-bin/wetlands/report.pl?smode=DOIW&doiw_refcodelist=$1 |
Robot and gadget jobs | It may be possible to scrape IDs from the database and then import into Wikidata using mix-and-match |
- Motivation
The Australian Wetlands Database Directory of Important Wetlands is the authoritative reference managed by the Australian Government Department of the Environment listing important wetland (Q170321)s within Australia (Q408). Within the database, numerous fields of additional data exist such as location, area, elevation, wetland type, various descriptions and justification for categorisation as an important wetland. Approval of this property would significantly enhance Wikidata's understanding of Australian wetlands (natural environment), and increase understanding of the Ramsar Convention (Q170170). Dhx1 (talk) 11:22, 22 November 2015 (UTC)
- Discussion
- Support Seem usefull. --Fralambert (talk) 04:12, 4 February 2016 (UTC)
- Support. author TomT0m / talk page 18:25, 22 February 2016 (UTC)
- @TomT0m, Dhx1: Done --Fralambert (talk) 03:06, 5 March 2016 (UTC)
INSEE region code
Description | number sequence for the identification of regions in France |
---|---|
Data type | External identifier |
Domain | region of France (Q36784) |
Allowed values | chaîne de caractères |
Example | Brittany (Q12130) → 53 |
Format and edit filter validation | 2-digit number between 01 and 94 (\d{2}) |
Source | http://www.insee.fr/fr/methodes/default.asp?page=nomenclatures/cog/codes_regions_2016.htm |
- Motivation
We already have other identifiers from the Code officiel géographique : INSEE municipality code (P374) for communes and INSEE canton code (P2506) for cantons. This proposal fills the gap for regions. Ash Crow (talk) 14:46, 27 February 2016 (UTC)
- Discussion
- Support. But this is of limited use, really. Thierry Caro (talk) 18:26, 1 March 2016 (UTC)
- Support --Fralambert (talk) 23:12, 3 March 2016 (UTC)
- @Ash Crow, Thierry Caro: Done C'est fait. --Fralambert (talk) 03:38, 5 March 2016 (UTC)
INSEE departement code
Description | number sequence for the identification of departements in France |
---|---|
Data type | External identifier |
Domain | department of France (Q6465) |
Allowed values | chaîne de caractères |
Example | Côtes-d'Armor (Q3349) → 22 |
Format and edit filter validation | 2-digit number between 01 and 19 or between 21 and 95, or values 2A, 2B, 69D, 69M, 3-digit number starting with 97 or 98. |
Source | http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement/2015/txt/depts2015.txt |
- Motivation
We already have other identifiers from the Code officiel géographique : INSEE municipality code (P374) for communes and INSEE canton code (P2506) for cantons. This proposal fills the gap for departements. Ash Crow (talk) 14:52, 27 February 2016 (UTC)
- Discussion
- Support. Thierry Caro (talk) 18:26, 1 March 2016 (UTC)
- Support. --Fralambert (talk) 23:24, 1 March 2016 (UTC)
- @Ash Crow, Thierry Caro: Done --Fralambert (talk) 03:47, 5 March 2016 (UTC)
driving side
Description | Whether vehicles in a state must drive on the left, or the right. |
---|---|
Data type | Item |
Domain | sovereign states |
Allowed values | left (Q13196750) or right (Q14565199) (or dedicated items) |
Example | United Kingdom (Q145) → left (Q13196750) |
- Motivation
Basic but essential info. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 4 March 2016 (UTC)
- Discussion
- Support, although the domain should be geographic regions rather than sovereign states as e.g. Gibraltar and Hong Kong drive on the opposite side to the United Kingdom and China respectively. This could also be done with instance of (P31) and an item "region where traffic drives on the left" (or right) I suppose, but that feels clumsier. Either way applies to part, aspect, or form (P518) should be available as a qualifier. Thryduulf (talk: local | en.wp | en.wikt) 14:56, 4 March 2016 (UTC)
ːWe have driving side (P1622), what else is that used for? -- Innocent bystander (talk) 15:11, 4 March 2016 (UTC)
Withdrawn - I missed driving side (P1622), sorry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:24, 4 March 2016 (UTC)
topographic prominence
Description | For any given summit, this would store how higher it is than its highest base. |
---|---|
Represents | topographic prominence (Q656751) |
Data type | Number (not available yet) |
Domain | mountain (Q8502) |
Allowed values | From 0 to 8,848 m, which is the highest possible value, the one that applies to Mount Everest (Q513). |
Example | Pico da Neblina (Q739484) → 2,886 m |
- Motivation
When it comes to numbers, mountains should not be dealt with only by looking at their altitude. We should store other data such as topographic prominence (Q656751). Thierry Caro (talk) 11:00, 27 February 2016 (UTC)
- Discussion
Eventually, we can probably use height (P2048) with qualifiers. Thierry Caro (talk) 20:38, 1 March 2016 (UTC)
- Comment Except for Everest, not sure if it's that useful to combine the two in the same field.
--- Jura 21:05, 1 March 2016 (UTC)- There is no mixing because elevation above sea level (P2044) is for altitude. Thierry Caro (talk) 01:13, 2 March 2016 (UTC)