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
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)
- No. This property should be for YouTube user names, type=string, for the same reasons that we don't store full URLs for other identifiers. Other properties may be created for YouTube channels, if needed. We shouldn't muddle two types of identifier in this way. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:12, 23 July 2015 (UTC)
- What's your plan for Donald Trump? --- Jura 15:32, 23 July 2015 (UTC)
- Support I looked at YouTube's API and they distinguish user names from channel IDs. I also found [1], it seems the Donald Trump example above is a custom URL, not a user name or channel ID. I don't think storing the entire URL would be a very structured way of storing the data. - Nikki (talk) 17:48, 23 July 2015 (UTC)
- The link you provided is most helpful, but it seems they are dropping the "legacy username" from the API. --- Jura 19:26, 23 July 2015 (UTC)
- @Nikki: Youtube removed what they call the "legacy username" from their api and exclude the creation of new ones. For new users, only "custom URI" become available and we need to include these in one way or the other. The proposal below for a single URI based property seems better structured (it's called uniform identifier for a reason) and consistent with other properties for complex naming schemes. --- Jura 08:58, 1 August 2015 (UTC)
- As you missed it above, I'll repeat: YouTube says that, while user names are no longer issued, existing names (and the URLs of which they are part) are still valid and may still be used. If you wish to start an RfC to change our policy on identifiers to always store full URIs rather than the UID component, please do so in an appropriate forum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 1 August 2015 (UTC)
- Can you provide us with a link to what you describe as policy? --- Jura 10:45, 1 August 2015 (UTC)
- YouTube's API still supports the username using the "forUsername" parameter (see [2] and [3]). I don't think that storing a single URL property is better structured. It would combine multiple incompatible things into a single property (channel ID and username require different API queries, custom URL doesn't seem to be usable in the API at all). There are also many possible URLs for the same ID or name (http vs https, www vs no www, desktop vs mobile, trailing slash vs no trailing slash, etc) which is not a sign of well structured data. - Nikki (talk) 17:42, 1 August 2015 (UTC)
- You are right about the "forUserName" api parameter. It seems that v3 limited the use of legacy usernames, but still allows this. CustomURLs probably need to use the query in the api. [4]. If one relies on the api, one should be prepared to process URLs
The main use for any of these access methods is to actually go to a channel. This works well with URLs and one of the issues we had with the current solution is that this isn't always possible. As any string, we can easily normalize URLs. Even for such simple things as Twitter account names, you already had to do quite a lot of normalization. If actual URLs are used, this is easier, as the input is already limited and we can define the correct format beforehand. --- Jura 06:05, 2 August 2015 (UTC)
- 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 Twitter username (P2002), Instagram username (P2003) etc. However, youtube has different url formats (https://www.youtube.com/<name> and https://www.youtube.com/user/<name> so unfortunately in this case the approach fails. --Pasleim (talk) 19:51, 4 October 2015 (UTC)
- @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)
- 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)
- 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)
- "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 (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 quality (P1552) ? author TomT0m / talk page 10:01, 26 November 2015 (UTC)
- Comment @TomT0m: Thanks, I had not seen that property. However, when I look at how it is being used, its not quite the same. Take for example fictional character (Q95074), and given name (Q202444). That's not really a defining attribute. A fictional character with no-name would still be a fictional character. What I had in mind was the basic and obvious attribute, which is absolutely mandatory in order for an item to belong to that class. Such as a venomous snake is venomous, otherwise it is not a venomous snake. Danrok (talk) 13:08, 26 November 2015 (UTC)
- This seems too domain-specific. What is interesting to one domain ("list of tallest buildings" -> architecture) may be less interesting to another domain ("buildings pioneering the use of x-type construction"). "has quality" seems sufficient on the point. --Izno (talk) 17:58, 28 December 2015 (UTC)
Weak support.I saw that freshwater marsh (Q31455) is instance of (P31) marsh (Q30198), but its defining characteristic is that it's fresh water (Q102192). Should I use has part or parts (P527)? That seems like I'm only listing one part of many, which isn't right. made from material (P186) sort of infers that something is human-made. But "defining characteristic" seems just right. Runner1928 (talk) 22:05, 6 January 2016 (UTC)- Oppose. Use has quality (P1552), with preferred rank if it's really necessary. has quality (P1552) can express perfectly well that height is a sine qua non of skyscrapers; the proposed property doesn't really add anything. Swpb (talk) 20:48, 7 January 2016 (UTC)
- perfect. Unless Danrok notes a situation in which has quality (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)
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 (Q2111) numeric value (P1181) 299 792 458 meter per second. In future the WikiBase repo software can use this property for the classic form {{PLURAL:$1|}}
(or other similar), and a user can see speed of light (Q2111) numeric value (P1181) 299 792 458 meters per second.
β16 - (talk) 09:53, 26 January 2016 (UTC)
- Discussion
- Support per requester. The "non-singular value with singular unit" problem isn't urgent, but it is a problem. Swpb (talk) 17:51, 26 January 2016 (UTC)
- Comment some languages don't use the plural when there is a number already indicating the quantity (Hungarian) while other languages may use different plurals depending on the number preceding the noun (Russian). So, what I'm saying is, proceed with caution :). – Máté (talk) 18:04, 27 January 2016 (UTC)
- Oppose. First of all, this is linguistic data, which is Wiktionary's domain. Second, this would result in a full extra statement for every language for every item. (Several billion statements.) We have "label" as a separate type of data for a reason. Third, regarding the example you gave, we already have P558 (P558), which is probably preferable to having the full text anyway. --Yair rand (talk) 22:46, 31 January 2016 (UTC)
- Comment The question isn't if this is someone's reserved turff or not, but can this be provided to users in a structured form or not? If it's a list in PDF format, it would be with Commons and possibly transcribed at Wikisource, but that couldn't be made use of here or elsewhere for specific items either. Wikidata is the provider for structured data.
--- Jura 07:23, 2 February 2016 (UTC)
- 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)
- 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)
Done @Nikki, Thryduulf, Laboramus, Srittau, Kaldari, ArthurPSmith:--Micru (talk) 17:15, 27 February 2016 (UTC)
comment
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)
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)
- @Spinster, Multichill, Runner1928, Filceolaire, Edgars2007, Jane023: - Done ArthurPSmith (talk) 21:56, 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
- 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 | v = d/t (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
Notified participants of WikiProject Physics Notified participants of WikiProject Chemistry Notified participants of WikiProject Mathematics
- What about saying "uncertainty corresponds to" (or "+- corresponds to"). It would be item-datatype and could link to 1-sigma, 2-sigma, etc. Otherwise I think many people will use +-0 for numbers and only add the uncertainty in the qualifiers. --Tobias1984 (talk) 09:28, 28 October 2015 (UTC)
- What about the following changes in your example above?
- orbital eccentricity (P1096):
0.8524512679233956 ± 0.00028691 (1 sigma)
- orbital eccentricity (P1096):
0.8524512679233956 ± 0.00028691 (1 σ)
- 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)
- 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)
- 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 Erchamion (Q725935) => The Lord of the Rings (Q15228) |
Format and edit filter validation | (exemple : 7 chiffres peuvent être validés avec le filtre d'édition Special:AbuseFilter/17) |
Robot and gadget 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)
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)
- 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)
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)
- 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)
- 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 (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)
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)
- 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)
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 plosive (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 (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)
- also, @Charles Matthews: Andrew Gray (talk) 12:30, 4 November 2015 (UTC)
- Comment. This limits DNB entries to the first edition and first two supplements. i.e. those currently in the US public domain and so on Wikisource. There are nearly ten further DNB volumes (decade supplements, plus one volume for people who were afterthoughts), before the ODNB arrived in 2004 with actual identifiers. Therefore this property is somewhat artificial from a bibliographical point of view. In other words, one can imagine cases where described by source (P1343) would still have to be used for the DNB. I don't object, but the proposal has to be seen as ad hoc. Charles Matthews (talk) 13:39, 4 November 2015 (UTC)
- Oppose All encyclopedias should be handle same way. I prefer the solution with described by source (P1343), which allow to add new encyclopedia without a request a new property. -- Sergey kudryavtsev (talk) 04:08, 5 November 2015 (UTC)
- Oppose per discussions Wikidata:Property proposal/Archive/31#DNB entry at Wikisource and Wikidata:Property proposal/Archive/31#Catholic Encyclopedia entry at Wikisource --Pasleim (talk) 09:22, 11 November 2015 (UTC)
- 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.com major league player ID (P1825) already exists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:53, 3 March 2016 (UTC)