User:Joshbaumgartner/property proposals
category contains
[edit]Data type | Item |
---|---|
Template parameter | in SPARQL form, on Commons c:Template:Category contains (experimental) |
Domain | category items |
Allowed values | class items |
Example | Category:Grade I listed buildings in Bedfordshire (Q8497784) → building (Q41176), with qualifiers * located in the administrative territorial entity (P131) → Bedfordshire (Q23143), * heritage designation (P1435) → Grade I listed building (Q15700818) |
Robot and gadget jobs | Move existing statements on category items using is a list of (P360) to use this property instead |
See also | is a list of (P360), category's main topic (P301), category combines topics (P971) |
- Motivation
We currently have 12,434 items that are categories using is a list of (P360) for this purpose (tinyurl.com/hftsk55
), using this format. This has been approved in an RFC, however before that close the question seemed to create a lot of dispute at Property talk:P360.
This kind of specification allows software like Reasonator to generate automatic lists of items with properties that appear to meet the criteria, which can then be compared with the current content of the actual list or category -- see for example the list offered by Reasonator on its page [1] for the list article Grade I listed buildings in Bedfordshire (Q5591762).
Coming back to this debate a year on, it seems to me it would be useful to separate the two into two parallel properties -- P360 specifically for lists, and this property specifically for categories. This would then mean that all uses of P360 would be for lists, all uses of the new property would be for categories. This would avoid the 'bad smell' of using a property called "is a list of" on categories, which definitely shouldn't be confused with lists; and it could help query performance, since excluding lists or excluding categories can be costly. Jheald (talk) 17:02, 11 February 2017 (UTC)
- Discussion
- Support so I assume you would transition all the P360's on categories to this new property? I think it's fine to be more specific like this, so I support it. ArthurPSmith (talk) 18:30, 13 February 2017 (UTC)
- Support per the thorough consideration given above. --Swpb (talk) 16:25, 15 February 2017 (UTC)
- Support. Thank you for proposing this. I agree that this would make creating lists easier and more flexible. YULdigitalpreservation (talk) 14:52, 16 February 2017 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 24 February 2017 (UTC)
- @Jheald: The property is currently missing an English description. ChristianKl (talk) 07:19, 25 February 2017 (UTC)
- Oppose category combines topics (P971) should do.
--- Jura 10:31, 25 February 2017 (UTC)- @Jura1: That property fails to express how the categories are combined. It does not contain sufficient information to automatically be able to write a search query to find corresponding items, in the way is a list of (P360) does, which this property would be modelled on.
- See also on Commons, the positive response from User:Astinson (WMF) (diff) to the idea of building information of this kind on Commons, with similar potential for automated searches, as part of preparations towards structured data there. This property would help that a lot, for when there are parallel categories here to Commons categories. Jheald (talk) 18:37, 2 March 2017 (UTC)
- I think it works even better than is a list of (P360). Have a look at the first sample: Q7068416.
--- Jura 20:40, 2 March 2017 (UTC)- @Jura1: The use of related property (P1659) is interesting, I hadn't seen that before with category combines topics (P971). I'm not sure that "see also" is quite right, perhaps some more specific qualifier eg "object of" might be an idea. But the shape is interesting.
- I suppose I am used to is a list of (P360), and there are a number of uses on lists that could be transferred straight over. (And, equally, a number of cases where we have parallel lists and categories, that I can see advantages in treating in the same way, to result in similarly parallel specifications).
- Something I like about P360 is that it tells you immediately and clearly what the subject matter is: this is a list of people; this is a list of paintings; etc, that then is specified in more detail with the qualifiers -- which I miss with your design. (Indeed, you don't seem to be specifying P31 Q5 at all -- which is definitely information that it is useful for machine-parsing the category).
- But I am interested -- what do you see as the advantages of your model of using P971; and what disadvantages do you see with the similar-to-P360 approach? Jheald (talk) 21:29, 2 March 2017 (UTC)
- You are right, the sample could include Q5 as well. I did suggest a more specific qualifier, but people weren't interested or preferred P1659. As the result on my application is the same, it doesn't matter much:
- It works for links on Wikidata:Database reports/items without claims categories/eswiki allowing to add statements to items lacking them.
--- Jura 21:35, 2 March 2017 (UTC)- @Jura1: But what do you see as particular advantages or disadvantages between the two forms? I've set out above why on balance I like the idea of something a bit more similar to is a list of (P360), which is already widely deployed. But what do you think are reasons to prefer or not prefer one over the other? Jheald (talk) 21:47, 2 March 2017 (UTC)
- P971 is closer to Wikidata's incremental way of building things. It allows to specify parts that may not be included in statements to be added. I use less P360 as I think it relies too much on qualifiers. I don't see much of a problem converting the few uses of P360 on categories to category combines topics (P971).
--- Jura 21:57, 2 March 2017 (UTC)
- P971 is closer to Wikidata's incremental way of building things. It allows to specify parts that may not be included in statements to be added. I use less P360 as I think it relies too much on qualifiers. I don't see much of a problem converting the few uses of P360 on categories to category combines topics (P971).
- @Jura1: But what do you see as particular advantages or disadvantages between the two forms? I've set out above why on balance I like the idea of something a bit more similar to is a list of (P360), which is already widely deployed. But what do you think are reasons to prefer or not prefer one over the other? Jheald (talk) 21:47, 2 March 2017 (UTC)
- @Jura1:, for me, your example of Category:Dutch politicians (Q7068416) is distinctly different than this proposal. It claims that Category:Dutch politicians (Q7068416) -> category combines topics (P971) -> Kingdom of the Netherlands (Q29999) and politician (Q82955). But neither of those are sub-categories or topics under Category:Dutch politicians (Q7068416), which is the point of this proposal as I understand it, and so category combines topics (P971) isn't really valid to use for the purpose proposed here. Josh Baumgartner (talk) 16:26, 1 May 2017 (UTC)
- I think both can be used to build the same query. P971 just offers more flexibility. The exception may be sample you mention below.
--- Jura 03:42, 2 May 2017 (UTC)
- I think both can be used to build the same query. P971 just offers more flexibility. The exception may be sample you mention below.
- I think it works even better than is a list of (P360). Have a look at the first sample: Q7068416.
- See also on Commons, the positive response from User:Astinson (WMF) (diff) to the idea of building information of this kind on Commons, with similar potential for automated searches, as part of preparations towards structured data there. This property would help that a lot, for when there are parallel categories here to Commons categories. Jheald (talk) 18:37, 2 March 2017 (UTC)
- Support after reading the above discussion I'm more convinced by Jheald's reasonings in support of this method than Jura1's alternatie. Thryduulf ( talk) 08:35, 12 April 2017 (UTC)
- Question Category:Aircraft by registration (Q29642098) has more than 70,000 sub-categories. Would each of these (that have a WD item anyway) have its own claim under Category:Aircraft by registration (Q29642098)? Josh Baumgartner (talk) 16:26, 1 May 2017 (UTC)
- @Jheald: I don’t really get the point. We already know from the item type if it’s a list or a category, so there is no need for two properties. I don’t really understand the « excluding list or categories » need as it’s enough to just select lists ( instance of wikimedia list article ) or categories or both and it’s just routine not costly sparql. No need to exclude anything. Did I miss anything ? author TomT0m / talk page 11:36, 20 May 2017 (UTC)
- @Jheald: Can you add a description for this property? ChristianKl (talk) 11:05, 22 May 2017 (UTC)
@Jheald, ArthurPSmith, Swpb, YULdigitalpreservation, Pigsonthewing: @ChristianKl, Joshbaumgartner, Jura1, TomT0m: Done After reading the conversation, it seems like a useful addition to fill the gaps of category combines topics (P971).--Micru (talk) 13:29, 15 September 2017 (UTC)
Changed
[edit]Description | Changed (or revised/altered/modified) - Anything that has changed at a given point in time |
---|---|
Data type | Point in time |
Allowed units | Same as start time (P580) |
Example | Kathmandu Valley (Q970717) -> heritage designation (P1435) -> World Heritage Site (Q9259) -> changed -> 2006 (ref) |
Planned use | UNESCO heritage sites via en:Template:Infobox World Heritage Site/Wikidata, but there are obviously wider applications |
- Motivation
Unless I'm mistaken, we don't currently seem to have any way to mark that something was changed/modified/altered/revised on a given date. This would seem like a good generic property to add so that we can mark when this happens. Thanks. Mike Peel (talk) 22:56, 2 May 2017 (UTC)
- Discussion
- Question For the provided example, wouldn't it work to use ⟨ Kathmandu Valley (Q970717) ⟩ heritage designation (P1435) ⟨ World Heritage Site (Q9259) ⟩? Josh Baumgartner (talk) 23:29, 2 May 2017 (UTC)
start time (P580) ⟨ 2006 ⟩- @Joshbaumgartner: The start date in this case is 1979; it was then revised in 2006. So the structure you're saying is already in use for the 1979 value (see Kathmandu Valley (Q970717)), but I can't figure out how to indicate the change in 2006. Thanks. Mike Peel (talk) 14:48, 3 May 2017 (UTC)
- @Mike Peel: Got it. From my quick read it was what UNESCO calls a 'Minor Modification' to the boundaries of the site. It sounds like we need some way of capturing what the change was. What about ⟨ Kathmandu Valley (Q970717) ⟩ significant event (P793) ⟨ Minor Modification ⟩and referencing the UNESCO docs? It is a little tricky capturing a border change when at the moment we aren't capturing the original or current borders. Josh Baumgartner (talk) 20:57, 3 May 2017 (UTC)
point in time (P585) ⟨ 2006 ⟩
- @Mike Peel: Got it. From my quick read it was what UNESCO calls a 'Minor Modification' to the boundaries of the site. It sounds like we need some way of capturing what the change was. What about
- @Joshbaumgartner: The start date in this case is 1979; it was then revised in 2006. So the structure you're saying is already in use for the 1979 value (see Kathmandu Valley (Q970717)), but I can't figure out how to indicate the change in 2006. Thanks. Mike Peel (talk) 14:48, 3 May 2017 (UTC)
- Comment Just to know that something changed on a certain date is not really informative. More interesting is to know what changed when. In case of Kathmandu Valley (Q970717) the size of the area was adapted. This could be modelled as follows:
- ⟨ Kathmandu Valley (Q970717) ⟩ area (P2046) ⟨ 275, 86 ha ⟩
start time (P580) ⟨ 1979 ⟩
end time (P582) ⟨ 2006 ⟩ - or ⟨ Kathmandu Valley (Q970717) ⟩ significant event (P793) ⟨ reduction of the property ⟩--Pasleim (talk) 18:01, 3 May 2017 (UTC)
point in time (P585) ⟨ 2006 ⟩- @Joshbaumgartner, Pasleim: The logic I was using here was "WHS inscription changed on this date" (which covers the what and the when ;-) ). It seems most natural to place that alongside the start time for that heritage status, as a "change". Defining a new type of significant event would work, but means including that information in a separate property rather than as a qualifier for heritage designation (P1435). Defining what exactly has changed could be ... messy. It may not be trivial to say what the change was in all cases, and also there could be cases where the entry covers *both* the WHS part of the site and the wider area, in which case qualifiers of WHS need to be put everywhere... Perhaps @John Cummings (as Wikimedian in Residence at UNESCO) can provide some insight into what could be done here as well. Thanks. Mike Peel (talk) 21:23, 3 May 2017 (UTC)
- I've applied a workaround (Q457174) of ⟨ Kathmandu Valley (Q970717) ⟩ significant event (P793) ⟨ UNESCO World Heritage Site record modification (Q29778318) ⟩, which is now in use in the infobox, but we should try to find a better solution to this! Thanks. Mike Peel (talk) 02:38, 5 May 2017 (UTC)
point in time (P585) ⟨ {{{5}}} ⟩
- I've applied a workaround (Q457174) of
- @Joshbaumgartner, Pasleim: The logic I was using here was "WHS inscription changed on this date" (which covers the what and the when ;-) ). It seems most natural to place that alongside the start time for that heritage status, as a "change". Defining a new type of significant event would work, but means including that information in a separate property rather than as a qualifier for heritage designation (P1435). Defining what exactly has changed could be ... messy. It may not be trivial to say what the change was in all cases, and also there could be cases where the entry covers *both* the WHS part of the site and the wider area, in which case qualifiers of WHS need to be put everywhere... Perhaps @John Cummings (as Wikimedian in Residence at UNESCO) can provide some insight into what could be done here as well. Thanks. Mike Peel (talk) 21:23, 3 May 2017 (UTC)
- Oppose Use start and end dates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:59, 5 May 2017 (UTC)
- @Pigsonthewing: How, exactly, in the example I've given? It's neither a start nor an end... Thanks. Mike Peel (talk) 22:05, 6 May 2017 (UTC)
- Mike Peel, thanks very much for trying to tackle this, I have tried to think about this before with no luck. I had thought about trying to show it through qualifiers in 'has part' being added or taken away at different dates or even by providing different area maps. I think this issue is likely to appear in many other registers where a member has changed over time. If you think this is the best way of doing that then I trust you are correct :) --John Cummings (talk) 10:53, 8 May 2017 (UTC)
- Comment I've used significant event (P793) this way for historical clothing that has been altered to a later style: ⟨ Layton jacket (Q6759619) ⟩ significant event (P793) ⟨ alteration (Q28873693) ⟩. - PKM (talk) 01:11, 21 July 2017 (UTC)
point in time (P585) ⟨ {{{5}}} ⟩
Not done Lack of support.--Micru (talk) 14:33, 15 September 2017 (UTC)
commanded by
[edit]Description | The commander of a military unit/army/security service |
---|---|
Represents | human (Q5) |
Data type | Item |
Template parameter | en:Infobox military unit, parameter: commander1... |
Domain | military unit (Q176799) (and sub-domains) |
Example | Air Force Space Command (Q407203) → John W. Raymond (Q6262488) |
Planned use | he:Template:יחידה |
See also | commander of (DEPRECATED) (P598), colonel-in-chief (P3460), authority (P797) |
- Motivation
I would like to suggest a property to be added to military units and security service for the commander. Eran (talk) 17:58, 29 March 2017 (UTC)
- Discussion
- Comment I added a few "see also".
--- Jura 11:31, 19 April 2017 (UTC) - Support as proposed. Josh Baumgartner (talk) 18:02, 1 May 2017 (UTC)
- @Eran: Why isn't commander of (DEPRECATED) (P598) enough? Given the current name I also fear that users confuse it with commander of (DEPRECATED) (P598). ChristianKl (talk) 09:33, 26 May 2017 (UTC)
- commander of (DEPRECATED) (P598) can only be used for entities with instance of (P31)=person (Q215627). So this property is assignment from the other direction. ChristianKl: As for the name you are right, but I couldn't think of a better name - Any better suggestion for name is more than welcome. Eran (talk) 13:11, 30 June 2017 (UTC)
- @ערן: How about "has commander"? ChristianKl (talk) 13:38, 30 June 2017 (UTC)
- @ChristianKl: sounds like boolean value :) Maybe "Commanded by" Eran (talk) 13:40, 30 June 2017 (UTC)
- Okay, then we take "commanded by" for now. ChristianKl (talk) 19:42, 30 June 2017 (UTC)
- @ChristianKl: sounds like boolean value :) Maybe "Commanded by" Eran (talk) 13:40, 30 June 2017 (UTC)
- @ערן: How about "has commander"? ChristianKl (talk) 13:38, 30 June 2017 (UTC)
- commander of (DEPRECATED) (P598) can only be used for entities with instance of (P31)=person (Q215627). So this property is assignment from the other direction. ChristianKl: As for the name you are right, but I couldn't think of a better name - Any better suggestion for name is more than welcome. Eran (talk) 13:11, 30 June 2017 (UTC)
- Oppose. No need for an inverse of commander of (DEPRECATED) (P598). --Yair rand (talk) 23:56, 4 September 2017 (UTC)
- @Yair rand: Please explain why there is no need of inverse for P598, because this is definitely required to list the officers who commanded a military unit. Krishna Chaitanya Velaga (talk) 12:49, 2 December 2017 (UTC)
- @Krishna Chaitanya Velaga: Adding a redundant property pointing the other direction does not help list the commanding officers. That information should already be there, using the commander of (DEPRECATED) (P598) property. Duplicating it does not make Wikidata more complete. --Yair rand (talk) 17:52, 3 December 2017 (UTC)
- @Yair rand: Please explain why there is no need of inverse for P598, because this is definitely required to list the officers who commanded a military unit. Krishna Chaitanya Velaga (talk) 12:49, 2 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 15:15, 29 September 2017 (UTC)
- Support This is definitely required. It is a significant data for military formations, has a big scope. --Krishna Chaitanya Velaga (talk) 16:23, 13 October 2017 (UTC)
- Support Useful in many infoboxes on Wikipedia. Danrok (talk) 23:12, 23 October 2017 (UTC)
- Oppose If needed extend domain of commander of (DEPRECATED) (P598) instead. -- JakobVoss (talk) 19:54, 11 November 2017 (UTC)
- The property proposal here is the inverse of commander of (DEPRECATED) (P598), not a superset of it. Deryck Chan (talk) 12:54, 15 December 2017 (UTC)
- Support Clearly needed Pmt (talk) 21:17, 19 November 2017 (UTC)
- Support. I think Eran has demonstrated a plausible case for an inverse property for commander of (DEPRECATED) (P598) to be used in infoboxes about military units. Deryck Chan (talk) 12:54, 15 December 2017 (UTC)
- @ערן, Jura1, Joshbaumgartner, ChristianKl, Yair rand, Krishna Chaitanya Velaga: @ديفيد عادل وهبة خليل 2 , Danrok, JakobVoss, Pmt, Deryck Chan: Done ArthurPSmith (talk) 15:00, 2 February 2018 (UTC)
field of view
[edit]Description | extent of the observable world that can be seen or sensed by the item |
---|---|
Data type | Quantity |
Domain | sensors, optical devices, etc. |
Allowed units | degree, minute of arc, second of arc, radian, steradian, square degree, square minute |
Example | No. 30 Sighting Telescope (Q29048358) → 21 degree (Q28390) |
- Motivation
Distinct spec for items with a field of view. Existing properties don't seem to do the job. Josh Baumgartner (talk) 04:18, 29 March 2017 (UTC)
- Discussion
- Support --Mr. Moonlight (talk) 23:50, 30 March 2017 (UTC)
- Support sounds good to me ArthurPSmith (talk) 15:05, 1 May 2017 (UTC)
- Is there prior art of how this property gets called elsewhere? ChristianKl (talk) 08:51, 22 May 2017 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 28 May 2017 (UTC)
- @Joshbaumgartner: I removed the "ready" from this property proposal as I am now confused about what precisely you intended here. According to en:Field of view there are several different definitions of "field of view", including "angular field of view" (which seems to match your example), "linear field of view", and "angular area viewed by the instrument, in square degrees" which seems to measure a solid angle as your description suggests. Which is it? And if the first is intended, I think this property should be renamed "angular field of view" and of course the description fixed. ArthurPSmith (talk) 18:34, 5 June 2017 (UTC)
- @ArthurPSmith: There are different ways to measure field of view, but instead of making separate properties for each, I would think qualifiers would be able to allow this differentiation (determination method or standard (P459) and object of statement has role (P3831) come to mind). I've removed the 'solid angle' part from the description to avoid confusion. Josh Baumgartner (talk) 16:40, 6 June 2017 (UTC)
- @Joshbaumgartner, Mr. Moonlight, ChristianKl, Pigsonthewing: Ok, everything looked ready, so - Done ArthurPSmith (talk) 17:16, 6 June 2017 (UTC)
effective firing range
[edit]Description | distance within which a weapon can be used effectively |
---|---|
Data type | Number (not available yet) |
Template parameter | |range= in en:Template:Infobox Weapon |
Domain | weapon |
Allowed values | number |
Allowed units | metre (Q11573), kilometre (Q828224) |
Example | QJY-88 (Q6458018) → 1000m |
Robot and gadget jobs | probably |
- Motivation
(Add your motivation for this property here.) GZWDer (talk) 09:14, 17 January 2017 (UTC)
- Discussion
- Comment "firing range" is often the term used to describe a place where one can fire guns at targets. I think "weapon range" or perhaps "deadly range" would be a better name for this property. ArthurPSmith (talk) 19:22, 17 January 2017 (UTC)
- See en:Shooting range for use of the term, for example. ArthurPSmith (talk) 19:23, 17 January 2017 (UTC)
- Support with a better name, per Arthur. Added "kilometre" as an allowed unit, for artillery. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 17 January 2017 (UTC)
Oppose in the current form because the range of a weapon has many variable factors including the ammunition type, test conditions (weather, firing position), etc. For example, how would someone determine the range of a boomerang (Q131536)? I thought about whether determination method or standard (P459) could be a mandatory qualifier to determine how the range was calculated, but am not aware of standards which may be used to test the range of weapons. Are there standards which could be referred to with a determination method or standard (P459) property? If so, I'd be happy to change this vote to one of support as a testing standard should remove the variable factors. Dhx1 (talk) 12:23, 8 February 2017 (UTC)- Oppose As Dhx1. Weapon range is depending on several parameters and an interval should be used instead. Snipre (talk) 21:00, 22 February 2017 (UTC)
- Question @Snipre:, can you clarify? Specifically, any idea on how such an interval idea would be implemented? Josh Baumgartner (talk) 09:38, 19 April 2017 (UTC)
- @Joshbaumgartner: You have several types of ammunition which can be used on one weapon, so the first as explained above is to provide the ammunition type tested to define the range using determination method or standard (P459). The best is to modify the scope of the property and to put not the firing range but the maximal lethal distance. I am not a spacialist so the best is to ask to people working in the weapon domain to provide the correct definition. Snipre (talk) 05:50, 21 April 2017 (UTC)
- Question @Snipre:, can you clarify? Specifically, any idea on how such an interval idea would be implemented? Josh Baumgartner (talk) 09:38, 19 April 2017 (UTC)
- Support Knowing the effective range a weapon can be used to is very valuable. There may be many factors that go into determining what that range is for a particular weapon, but they are not always published. When they are available, of course qualifiers should be added. However, the fact that they are not always available is not a valid reason to not have a way to add the very important and pertinent information. If we don't have a property such as this, how do we capture the data in WD from a source that says, "the effective firing range of the 65 mm L/17 Cannon Model 13 (Q162404) is 6.8 km"? Josh Baumgartner (talk) 09:18, 17 April 2017 (UTC)
- Support (with a better name, perhaps "effective range" or "maximum effective range") per Joshbaumgartner. Thryduulf (talk) 21:53, 18 April 2017 (UTC)
- Support--Micru (talk) 07:54, 24 April 2017 (UTC)
- "effective range" and "maximum range" are two different things: for handguns the latter can easily be two or three (or more) times as much as the former. I would like to see two separate properties. (I agree that "firing range" is a place where guns are fired: maybe "effective range of gun"?). - Brya (talk) 15:59, 7 May 2017 (UTC)
- @Brya, Thryduulf, Joshbaumgartner, Snipre, Dhx1, ArthurPSmith: I renamed the property to "effective firing range". I prefer it over "effective range of gun" as it's likely also applicable to bows and similar range weapons. The wording matching the wording in the en-infobox. Can someone who has more domain knowledge write a good description? Otherwise, are there problems with creating the property under the name "effective range"? ChristianKl (talk) 12:35, 1 July 2017 (UTC)
- "effective range" or "effective firing range"? I think "effective range" is actually the better label, I'd support it with that label. ArthurPSmith (talk) 14:26, 3 July 2017 (UTC)
- I am fine with either label. In actual use, it can be honed if need be. Josh Baumgartner (talk) 17:03, 3 July 2017 (UTC)
- "effective range" or "effective firing range"? I think "effective range" is actually the better label, I'd support it with that label. ArthurPSmith (talk) 14:26, 3 July 2017 (UTC)
- Support usefull for description of cannons and artillery --Pmt (talk) 22:36, 1 July 2017 (UTC)
- Weak support to get estimate in kilometers or 100m. Should be replaced with more exact information if available over time. d1g (talk) 21:21, 31 July 2017 (UTC)
- @D1gggg, Pmt, Thryduulf, Dhx1, Pigsonthewing, Snipre: Can more of you add your opinions about which name you prefer? ChristianKl (talk) 08:54, 4 August 2017 (UTC)
- @GZWDer, Pigsonthewing, Dhx1, Joshbaumgartner, Thryduulf: @Snipre, Micru, Brya, ChristianKl, Pmt, D1gggg: Done ArthurPSmith (talk) 19:36, 24 August 2017 (UTC)
former name
[edit]Description | former name of the subject |
---|---|
Represents | former name (Q29569274) |
Data type | String |
Domain | Q5, Q43229, Q16334295 |
Example | U2 (Q396) → The Hype |
Planned use | Ingestion of 2500 Swiss theatre groups, some of which where formerly known under another name |
Robot and gadget jobs | Planning to use QuickStatements |
See also | start time (P580), end time (P582) |
- Motivation
I plan to ingest a database with Swiss theatre groups. Some of them were previousely known under another name. I know that one could work with start time or end time and a property such as Property:P1448, but most of the items in my database do not have a date that shows when they changed their names. Therefore, a more generic property is needed. Affom (talk) 09:22, 25 April 2017 (UTC)
- Discussion
Use end date with <somevalue>. – Máté (talk) 10:33, 25 April 2017 (UTC)
- Do you think this would lead to a better, more understandable solution than a new property former name? Affom (talk) 11:44, 25 April 2017 (UTC)
- Oppose Use official name (P1448), with an end-date qualifier. Make that qualifier "unknown value", where applicable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:03, 26 April 2017 (UTC)
- Oppose use official name (P1448), per Andy. Josh Baumgartner (talk) 22:18, 28 April 2017 (UTC)
- @Affom, Pigsonthewing, Joshbaumgartner, Máté: Not done, official name (P1448) with "unknown value" should work well enough. ChristianKl (talk) 11:08, 22 May 2017 (UTC)
magnification
[edit]Description | amount of optical magnification provided |
---|---|
Data type | Quantity |
Domain | sensors, optical devices, etc. |
Allowed units | degree |
Example | No. 30 Sighting Telescope (Q29048358) → 1.9 |
- Motivation
Distinct spec for optical devices. Existing properties don't seem to do the job. Josh Baumgartner (talk) 04:18, 29 March 2017 (UTC)
- Discussion
- Support Thryduulf (talk) 20:18, 5 May 2017 (UTC)
- Support this is more for microscopes (and camera lenses?) than for telescope I would think? ArthurPSmith (talk) 18:18, 8 May 2017 (UTC)
- Is there any prior art how other ontologies model this property? ChristianKl (talk) 21:00, 14 May 2017 (UTC)
- Most likely, but I don't have a specific one at hand. Josh Baumgartner (talk) 23:58, 23 May 2017 (UTC)
- Can you express the domain in terms of Wikidata items? That makes it setting the constraints clearer. ChristianKl (talk) 21:02, 14 May 2017 (UTC)
- I have in mind items which would be within appliance (Q1183543), though I don't necessarily think it needs to be constrained if others come up with different ways to use it. Josh Baumgartner (talk) 23:58, 23 May 2017 (UTC)
- @Joshbaumgartner: This could be ready, if you would address ChristianKl's concerns? ArthurPSmith (talk) 19:40, 15 May 2017 (UTC)
- Support Dhx1 (talk) 14:09, 30 July 2017 (UTC)
- @Joshbaumgartner, Thryduulf, ArthurPSmith, ChristianKl, Dhx1: magnification (P4163) has been created. Pamputt (talk) 21:52, 10 August 2017 (UTC)
Most valuable player
[edit]Description | The player who was chosen as the most value player of a tournament or of a match. |
---|---|
Data type | Item |
Template parameter | "player" in en:template:Infobox international football competition --> |
Example | UEFA Euro 2012 (Q22669) → Andrés Iniesta (Q43729) |
Source | external reference, Wikipedia list article, etc. |
Planned use | Add to all the items that their English article has the template |
Robot and gadget jobs | Yes |
See also | statistical leader (P3279) |
- Motivation
We need a property to show who was chosen as the most value player of a tournament or of a match. Is not always the statistical leader (with a criterion). Sometime some specialist choose the MVP according to many criterion or just one (like the hat-trick or to keep a clean sheet under resounding pressure). Please read the articles of most valuable player award (Q652965) and player of the match (Q1378679). This property applies to many sports, not just football. (There is also a best young player award. I don't know if I must propose another property.) Xaris333 (talk) 14:39, 21 December 2016 (UTC)
- Discussion
- Comment. One may use statistical leader (P3279) or significant person (P3342). Thierry Caro (talk) 08:37, 22 December 2016 (UTC)
- @Thierry Caro: hello. Just tell me how to use statistical leader (P3279) to show that someone was selected as the MVP of a tournament. There is no a criterion. A group of specialist decided who is the a MVP. We don't know if the player is selected based on a statistical record. And please give an example how to use significant person (P3342). Xaris333 (talk) 11:06, 22 December 2016 (UTC)
- Oppose, per the solution I outlined in Wikidata:Project chat/Archive/2016/12#Best player and best young player. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 22 December 2016 (UTC)
- The description shouldn't simply state the name of the property but do more. ChristianKl (talk) 10:32, 24 December 2016 (UTC)
- Oppose, as there are many awards given in various sports for superlative players or teams in events. Currently, one can add award received (P166) to the recipient. If we need an inverse property, then we should create an 'awarded to' property which is then added to the award item, but I'm not sure even this is needed. Josh Baumgartner (talk) 09:59, 19 April 2017 (UTC)
- Support if we are looking for usability then MVP/Best-on-(field|ground)/... makes perfect sense where it is awarded/judged. It seems that contributors would most likely enter the sporting result with all its components: teams playing, scores, date, best player, ... — and that is then how they are likely to want to retrieve that data. To me it doesn't make sense to put half the detail about an event in one spot, then put the MVP component against the player themself in another spot referring back to the primary event. Keep it together! If someone was constructing form input/import, that definitely is the case of how it would be best constructed. The addition and usability should clearly be considered. — billinghurst sDrewth 04:08, 24 April 2017 (UTC)
- Oppose, use
- @Snipre, Josh Baumgartner, Xaris333, Pigsonthewing, billinghurst, Thierry Caro: Not done. Follow Snipre's suggestion:
- significant person (P3342) = XXX
- Qualifier: award received (P166) = most valuable player award (Q652965) or player of the match (Q1378679). ChristianKl (talk) 20:46, 24 May 2017 (UTC)
- Comment somehow, these conversations and decisions with a determinant process need to flow back to pages like Wikidata:WikiProject Sports, or maybe something like Help:Sports. Otherwise this conversation will occur again, OR we have people doing their own individual 'innovations' of what they think is right. — billinghurst sDrewth 00:32, 25 May 2017 (UTC)
muzzle velocity
[edit]Description | the speed of a projectile at the moment it leaves the muzzle of a gun |
---|---|
Represents | muzzle velocity (Q920165) |
Data type | Number (not available yet) |
Template parameter | velocity at en:Template:infobox weapon |
Domain | weapon |
Allowed values | number |
Allowed units | m/s |
Example | AK-47 (Q37116) → 715m/s |
Robot and gadget jobs | probably |
- Motivation
(Add your motivation for this property here.) GZWDer (talk) 09:04, 17 January 2017 (UTC)
- Discussion
Oppose The notable variables for muzzle velocity are length of the barrel and the characteristics of the ammunition. How would this property allow both a weapon and a very specific manufacture of ammunition to be defined? One suggestion is to have a item:weapon property:fires_ammunition item:ammunition triple with a qualifier of muzzle velocity (Q920165). Or perhaps the qualifier should be Muzzle energy (Q1410940) instead? Dhx1 (talk) 12:34, 8 February 2017 (UTC)- Support There are variables, but they can be handled with qualifiers. This is a useful and specific specification for several weapons. For several weapons there may be a simple muzzle velocity specified in a source. For others it may have more breakdown for different ammunition or use cases, but that can be determined per the subject and is not a reason to stop this proposal. Josh Baumgartner (talk) 09:34, 19 April 2017 (UTC)
- @Joshbaumgartner, GZWDer: Please provide a working scheme and examples. It semm a good practice to me to decide on how to use b property before creating it. author TomT0m / talk page 11:25, 20 May 2017 (UTC)
- Support --Micru (talk) 07:53, 24 April 2017 (UTC)
- Support per Josh Baumgartner. - Brya (talk) 15:53, 7 May 2017 (UTC)
- Support — Music1201 talk 23:53, 17 June 2017 (UTC)
- Weak support in order to get estimates. d1g (talk) 21:23, 31 July 2017 (UTC)
- @GZWDer, D1gggg, Music1201, Brya, Micru, TomT0m: Done Created as muzzle velocity (P4137). ChristianKl (talk) 21:46, 1 August 2017 (UTC)
Wikimedia outline's main topic
[edit]Description | primary topic of this Wikimedia outline |
---|---|
Data type | Item |
Example | outline of knowledge (Q7112676) → knowledge (Q9081) |
- Motivation
Same motivation as Wikimedia portal's main topic (P1204) and is the inverse of Wikidata:Property_proposal/topic's_main_Wikimedia_outline. This is an important navigational structure within Wikipedia (i.e., en:Wikipedia:Outlines). Outlines have their own WikiProject (i.e., en:Wikipedia:WikiProject_Outlines). We can better classify outline articles in Wikidata as well as support the WikiProject by adding this property. Runner1928 (talk) 16:45, 27 April 2017 (UTC)
- Discussion
- Oppose Use the method demonstrated here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 29 April 2017 (UTC)
- That would be introducing a new meaning for P921. Why not just use P921 as a separate statement? --Yair rand (talk) 05:30, 3 May 2017 (UTC)
- It would not; but your solution could work also. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 7 May 2017 (UTC)
- That would be introducing a new meaning for P921. Why not just use P921 as a separate statement? --Yair rand (talk) 05:30, 3 May 2017 (UTC)
- Oppose Use Josh Baumgartner (talk) 21:04, 3 May 2017 (UTC)
- @Runner1928, Josh Baumgartner, Pigsonthewing: Not done, use main subject (P921) as described above. ChristianKl (talk) 19:00, 24 May 2017 (UTC)