Wikidata:Property proposal/military unit size

From Wikidata
Jump to navigation Jump to search

unit size[edit]

Originally proposed at Wikidata:Property proposal/Organization

   Not done
Descriptionsize classification of military unit
Representsmilitary unit size class (Q21506450)
Data typeItem
DomainQ176799
Allowed valuesQ21506450
Example 11st Armored Division (Q163673) military unit size military division (Q169534)
Example 2signals regiment (Q47423740) military unit size regiment (Q52371)
Example 3infantry squad (Q47250366) military unit size squad (Q207063)
Example 4Filo (Q62649248) military unit size squadron (Q679165)

Motivation[edit]

Permit connecting a military unit to the item related to its size. Josh Baumgartner (talk) 04:20, 11 April 2019 (UTC)[reply]

Discussion[edit]

  •  Support David (talk) 08:31, 11 April 2019 (UTC)[reply]
  • From the examples, it appears that this would be used for both classes of units and individual units. For the latter, wouldn't this be redundant with P31? Or would the P31 value be changed to something else? --Yair rand (talk) 20:35, 11 April 2019 (UTC)[reply]
    I am not sure exactly how Wikidata is handling these kinds of redundancies these days...whether instances inherit the properties of their class or if they are separately attached. As far as I have seen, there is not consistency. I am fine with actual implementation of the property matching whatever the prevailing method is, my point is only to bring it into existence so we can start attaching this information. Josh Baumgartner (talk) 02:21, 12 April 2019 (UTC)[reply]
  •  Oppose Redundant with instance of (P31). /ℇsquilo 06:53, 16 April 2019 (UTC)[reply]
  •  Support Arpyia (talk) 08:36, 11 May 2019 (UTC)[reply]
  •  Oppose It seems to me that instance of (P31)/subclass of (P279) is already enough to express the information currently. ChristianKl08:21, 8 June 2019 (UTC)[reply]
    • @ChristianKl: Your sentiment matches mine for a long time, but here is what I am struggling with, so perhaps you can help me out here: Nearly all non-identifier properties could be replaced with instance of (P31)/subclass of (P279), and I often see the argument made that a property should be deleted or not created because the information can be expressed already with P31/P279. And this is true, it can. But yet there is no policy that if it can be done at all with an existing property, that a new property can't be used, even if it offers an advantage. The fact is that while P31/P279 can express the literal connection between items, they are not good at providing context and they are difficult to reference correctly, as outside sources are not likely to tailor their descriptions and definitions to the structure of Wikidata classification. Distinct properties allow users, both machine and human, to more quickly access the data they seek. Using P31/P279 for example, a reader seeking the size of a unit would have to query each value of P31/P279 to ask it 'are you a size classification?', and this would potentially need to be done through several levels depending on how deep of a classification exists for the item. It would be an especially difficult problem to identify those items for which a link to a unit size classification has not been added yet (how recursively do you query the database until you give up?). On the other hand, a distinct property for 'unit size' would allow that information to be accessed directly from the item's page with no need for recursive queries, and both machine (by seeking the exact property) and humans (by reading the property label) would immediately be able to identify the desired information with a minimum of workload for both the user and the database. So a pretty simple example: Seeking the answer to this question, "What is the unit size of 223rd Squadron (Q62783320)?" If it has the statement 223rd Squadron (Q62783320) unit size squadron (Q679165) then a simple query 'return the value of P# (unit size) for Q62783320' is all that is needed. How complex would the query need to be if we only have P31/P279? Josh Baumgartner (talk) 03:40, 26 July 2019 (UTC)[reply]