Wikidata:Property proposal/type of unit used for this property
type of unit used for this property edit
| Description | the units for this property are all instances of this item |
|---|---|
| Data type | Item |
| Domain | properties |
| Allowed values | subclasses of unit of measurement (Q47574), currency (Q8142) |
| Example | price (P2284) → currency (Q8142), duration (P2047) → unit of time (Q1790144), length (P2043) → unit of length (Q1978718), |
- Motivation
We have P2237 (P2237) for listing individual units that can be used with a property but lots of properties which use units aren't restricted to specific units but to specific types of units.
In some cases (e.g. temperature) it's not really a problem because there aren't many units used. In other cases though, there's a lot of possible units. For example, the units for length (P2043) are any unit of length. There are 167 instances of unit of length (Q1978718). length (P2043) already lists 15 different units and there are about another 15 showing up as constraint violations on Wikidata:Database_reports/Constraint_violations/P2043#Units_statistics. I think it would be useful to have a way to say that the units for length (P2043) are any unit of length instead of trying to list every unit of length as a unit for the property.
I'm not sure exactly how this would interact with P2237 (P2237). My suggestion would be to use P2237 (P2237) when the property is defined in terms of a specific unit and this property if it can use any unit of a specific type.
@Pasleim: Pinging you because HarvestTemplates appears to be using P2237 (P2237), so you might be interested in this.
- Nikki (talk) 12:43, 16 April 2016 (UTC)
- Discussion
Comment I think this would be somewhat redundant. measured physical quantity (P111) is here to link units to quantity types already. We could reuse this property to do the same on properties, then we would have the set of all appliable properties by a simple query. author TomT0m / talk page 13:03, 16 April 2016 (UTC)
- I'm not sure how well that would work. The uses of P111 include things which shouldn't show up in a list of units, e.g. unit of area (Q1371562) (and that statement does not seem wrong to me) and P111 doesn't seem to be very widely used either so lots of things which should show up in a list of units probably won't. I think it would also not discourage people from adding lots of P2237 (P2237) statements because it wouldn't be obvious that P111 is being (somehow) used to define acceptable units, whereas this proposal is explicitly about which units are acceptable. - Nikki (talk) 14:11, 16 April 2016 (UTC)
- I proposed properties for dimensional analysis recently but it seems that it was rejected :/ But that statement seems wrong to me : an area is a measure of a surface. What's measured here is a surface (L*L in dimensional analysis (Q217113)
). The physical quantity should be Surface (Q297895) . The area is the number of surface units we can measure. author TomT0m / talk page 14:34, 16 April 2016 (UTC)
- I proposed properties for dimensional analysis recently but it seems that it was rejected :/ But that statement seems wrong to me : an area is a measure of a surface. What's measured here is a surface (L*L in dimensional analysis (Q217113)
- I'm not sure how well that would work. The uses of P111 include things which shouldn't show up in a list of units, e.g. unit of area (Q1371562) (and that statement does not seem wrong to me) and P111 doesn't seem to be very widely used either so lots of things which should show up in a list of units probably won't. I think it would also not discourage people from adding lots of P2237 (P2237) statements because it wouldn't be obvious that P111 is being (somehow) used to define acceptable units, whereas this proposal is explicitly about which units are acceptable. - Nikki (talk) 14:11, 16 April 2016 (UTC)
- Comment The problem with P2237 (P2237) is that it's somewhat redundant with the constraint template. Eventually both would be replaced by a new system of constraint properties. Obviously, a constraint that works is better than any property. Even if we would want units of length, we might not want any unit of length. The lists of allowed units might be the same for several properties ..
--- Jura 15:43, 16 April 2016 (UTC)- Why would it be replaced and what benefit would there be to replacing properties with new properties that mean the same thing? Surely it could just use existing properties where we already have them (format as a regular expression (P1793) is another). - Nikki (talk) 17:55, 16 April 2016 (UTC)
- Maybe Lydia wants to explain their development plan .. her role.
--- Jura 12:11, 17 April 2016 (UTC)
- Maybe Lydia wants to explain their development plan .. her role.
- Why would it be replaced and what benefit would there be to replacing properties with new properties that mean the same thing? Surely it could just use existing properties where we already have them (format as a regular expression (P1793) is another). - Nikki (talk) 17:55, 16 April 2016 (UTC)
Support The example Nikki is giving is convincing. I encountered similar problems with valuta. It's a bit silly to have to add a new currency to the possible units, when the property is applied to an item from a formerly unused country, while it is clear that it in accordance with the intended use of the property (like price (P2284)). In some cases P2237 (P2237) is still to be preferred. Lymantria (talk) 06:56, 4 May 2016 (UTC)- Support I'd be in favor of replacing all uses of P2237 (P2237) with this and either constraining that property to be single-valued when used or deleting it altogether (are there good examples where it's really needed?) This solution seems much better for almost all cases I can think of anyway. ArthurPSmith (talk) 17:48, 27 May 2016 (UTC)
@Nikki, Pasleim, Lymantria, ArthurPSmith: 
Done --Srittau (talk) 15:46, 29 May 2016 (UTC)