Wikidata

User:Joshbaumgartner/property proposals

< User:Joshbaumgartner

category contains edit

Data typeItem
Template parameterin SPARQL form, on Commons c:Template:Category contains (experimental)
Domaincategory items
Allowed valuesclass items
ExampleCategory: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 jobsMove existing statements on category items using is a list of (P360) to use this property instead
See alsois 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)
@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)
  •  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

   Not done
DescriptionChanged (or revised/altered/modified) - Anything that has changed at a given point in time
Data typePoint in time
Allowed unitsSame as start time (P580)
ExampleKathmandu Valley (Q970717) -> heritage designation (P1435) -> World Heritage Site (Q9259) -> changed -> 2006 (ref)
Planned useUNESCO 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 ? Josh Baumgartner (talk) 23:29, 2 May 2017 (UTC)
@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)  View with Reasonator View with SQID ⟩ significant event (P793) View with SQID ⟨ Minor Modification ⟩
point in time (P585) View with SQID ⟨  2006 ⟩
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)
 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)  View with Reasonator View with SQID ⟩ area (P2046) View with SQID ⟨ 275, 86 ha ⟩
start time (P580) View with SQID ⟨ 1979 ⟩
end time (P582) View with SQID ⟨ 2006 ⟩
⟨ Kathmandu Valley (Q970717)  View with Reasonator View with SQID ⟩ area (P2046) View with SQID ⟨ 167,27 ha ⟩
start time (P580) View with SQID ⟨ 2006 ⟩
or
⟨ Kathmandu Valley (Q970717)  View with Reasonator View with SQID ⟩ significant event (P793) View with SQID ⟨ reduction of the property ⟩
point in time (P585) View with SQID ⟨ 2006 ⟩
--Pasleim (talk) 18:01, 3 May 2017 (UTC)
@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 , 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)
  • 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)  View with Reasonator View with SQID ⟩ significant event (P793) View with SQID ⟨ alteration (Q28873693)  View with Reasonator View with SQID ⟩
    point in time (P585) View with SQID ⟨ {{{5}}} ⟩
    . - PKM (talk) 01:11, 21 July 2017 (UTC)

 Not done Lack of support.--Micru (talk) 14:33, 15 September 2017 (UTC)

commanded by edit

   Done: commanded by (P4791) (Talk and documentation)
DescriptionThe commander of a military unit/army/security service
Representshuman (Q5)
Data typeItem
Template parameteren:Infobox military unit, parameter: commander1...
Domainmilitary unit (Q176799) (and sub-domains)
ExampleAir Force Space Command (Q407203) → John W. Raymond (Q6262488)
Planned usehe:Template:יחידה
See alsocommander 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
  • @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)

field of view edit

   Done: field of view (P4036) (Talk and documentation)
Descriptionextent of the observable world that can be seen or sensed by the item
Data typeQuantity
Domainsensors, optical devices, etc.
Allowed unitsdegree, minute of arc, second of arc, radian, steradian, square degree, square minute
ExampleNo. 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 (P459) and object 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)

effective firing range edit

Descriptiondistance within which a weapon can be used effectively
Data typeNumber (not available yet)
Template parameter|range= in en:Template:Infobox Weapon
Domainweapon
Allowed valuesnumber
Allowed unitsmetre (Q11573), kilometre (Q828224)
ExampleQJY-88 (Q6458018) → 1000m
Robot and gadget jobsprobably
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)
  •  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 (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 (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)
     Support Changed vote to one of support after reading the discussion below. Dhx1 (talk) 13:35, 30 July 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 (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)
  •  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)
  •  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)
    • My preference is "effective range". Thryduulf (talk) 15:06, 4 August 2017 (UTC)
      • I do prefer effective firing range Breg Pmt (talk) 22:50, 5 August 2017 (UTC)

former name edit

   Not done
Descriptionformer name of the subject
Representsformer name (Q29569274)
Data typeString
DomainQ5, Q43229, Q16334295
ExampleU2 (Q396) → The Hype
Planned useIngestion of 2500 Swiss theatre groups, some of which where formerly known under another name
Robot and gadget jobsPlanning to use QuickStatements
See alsostart 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)
I do think it would be more consistent, more easy to query. For me that constitutes better. The current one is distinguished by its rank anyway. – Máté (talk) 18:18, 25 April 2017 (UTC)

magnification edit

   Done: magnification (P4163) (Talk and documentation)
Descriptionamount of optical magnification provided
Data typeQuantity
Domainsensors, optical devices, etc.
Allowed unitsdegree
ExampleNo. 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

   Not done
DescriptionThe player who was chosen as the most value player of a tournament or of a match.
Data typeItem
Template parameter"player" in en:template:Infobox international football competition -->
ExampleUEFA Euro 2012 (Q22669) → Andrés Iniesta (Q43729)
Sourceexternal reference, Wikipedia list article, etc.
Planned useAdd to all the items that their English article has the template
Robot and gadget jobsYes
See alsostatistical 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
You are answer is not solving the problem. Xaris333 (talk) 03:56, 4 January 2017 (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
significant person (P3342) = XXX
Qualifier: award received (P166) = most valuable player award (Q652965) or player of the match (Q1378679).
Snipre (talk) 11:03, 24 April 2017 (UTC)
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

Descriptionthe speed of a projectile at the moment it leaves the muzzle of a gun
Representsmuzzle velocity (Q920165)
Data typeNumber (not available yet)
Template parametervelocity at en:Template:infobox weapon
Domainweapon
Allowed valuesnumber
Allowed unitsm/s
ExampleAK-47 (Q37116) → 715m/s
Robot and gadget jobsprobably
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 Changing vote after reading discussion below. Dhx1 (talk) 13:29, 30 July 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

   Not done
Descriptionprimary topic of this Wikimedia outline
Data typeItem
Exampleoutline 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

See also edit

Retrieved from "https://www.wikidata.org/w/index.php?title=User:Joshbaumgartner/property_proposals&oldid=1916799897"