Wikidata:Property proposal/greater than
greater than / less than edit
Originally proposed at Wikidata:Property proposal/Generic
Not done
- Motivation
No existing property or combination of properties can succinctly express these basic statements, which are often defining features of items. There are two awkward, limited alternatives currently available:
- Statements of the form [subject]has characteristic (P1552)greater than (Q47035128) with qualifiers relative to (P2210) [item] and criterion used (P1013) [measure] – this does not allow the qualifiers to be made mandatory, as they must be for this kind of statement
- Statements of the form [subject]different from (P1889)[item] with criterion used (P1013) [measure], but this does not allow the direction of the difference to be specified.
Swpb (talk) 16:21, 8 January 2018 (UTC)
- Discussion
- I don't think a century has an age. ChristianKl ❪✉❫ 01:36, 9 January 2018 (UTC)
- Ok, poor example replaced. Swpb (talk) 13:05, 9 January 2018 (UTC)
Comment Something doesn't ring right with me about this, but I'm not sure. I want to think about it a bit. ArthurPSmith (talk) 18:24, 9 January 2018 (UTC)
- Is it that it's too obvious, so why doesn't it exist already? That was my first thought, but I can't think of any reason it shouldn't exist. If your concern is about these being used for trivial statements, the names or descriptions can make explicit that the item must be defined as having a greater or lesser value than the object. Or, if you're concerned about which part is the main statement and which is the qualifier, that can be turned around (at the risk of leaving a meaningless statement if the qualifier is missing): urban heat island (Q215712)greater thanrural area (Q175185)
criterion used (P1013)temperature (Q11466). Swpb (talk) 19:35, 9 January 2018 (UTC) - @Swpb: I think I'm bothered by all your examples being abstract. I'm not sure what the real implied meaning is, it seems a little too ambiguous. For concrete wikidata items, it seems to me you would just have the property set for each item, for example length (P2043), and then one object being greater or less than another is a simple matter of comparing numbers, there's no need for a wikidata property for it. In general how is one to pick the two items being compared? You suggest it's somehow part of the definition of one item vs the other, but I think if what you want is to better define an item via structured data we should look at all that goes into definining it (and the comparison object in cases like these). But maybe something like this is needed; still thinking about it... ArthurPSmith (talk) 17:19, 10 January 2018 (UTC)
- I'm really not sure I understand how abstraction is a problem; it's actually the point. Yes, these are classes of items; as you say, instances would have specific numerical values, and would not need this property. LZ 129 Hindenburg (Q217964) was a specific aerostat (Q1299477) with a specific density (Q29539) that could be given numerically. But aerostat (Q1299477) as a class does not have a specific density – what can be said about the density of aerostats in general is that it will always be less than that of air, by definition. Satellites can have very different masses, but they will always, by definition, be less massive than the bodies they circle; otherwise they are not satellites. These inequality relationships are central to the identity of the items, but right now there is no satisfactory way to express them. A complete definition of an item almost always requires several statements; sometimes one of those statements is that the item is larger, higher, deeper, etc. than another particular item, but not by a particular amount; that ought to be captured. Swpb (talk) 17:41, 10 January 2018 (UTC)
- @Swpb: Ok, I think my problem is that there's a context assumption missing in all these. An urban heat island is hotter than the *surrounding* rural area, bu it's not hotter than every possible rural area. A satellite is less massive than *the primary body it orbits*, but there can certainly be primary bodies that are less massive than a given satellite (e.g. Pluto is less massive than Earth's Moon, and many other moons in the solar system, but is primary body for its own moons). An "em-dash" is longer than an "en-dash" in a given font, but certainly not across differing fonts or even the same font set at different sizes. I'm concerned that these proposed properties will lead to incorrect inferences unless we can also somehow specify the context they are valid for. I'm not sure how to do that though. ArthurPSmith (talk) 16:55, 11 January 2018 (UTC)
- @ArthurPSmith: That's an interesting point, and one I think we can address. The context assumption should always be the same - the instance of the object meant is the one that corresponds with a given instance of the subject item (I'm striking the "novelette" example where this is not true). So not all rural areas, but the rural area(s) corresponding to (adjacent to) a given urban area; not all primary bodies, but the primary body corresponding to a given satellite. Since that pattern is always the same, we should be able to capture it in the title and/or description of the properties: something like "greater/less than corresponding instance of", with description "instances of the subject have a greater/lesser numerical value, by definition, than corresponding instances of the object, with respect to the given measure" (with emphasis on "corresponding"). A separate pair of properties could express that all instances of A are greater/less than all instances of B, if needed. Swpb (talk) 18:43, 11 January 2018 (UTC)
- @ArthurPSmith: I've changed the descriptions as I described above. Hopefully that addresses the issue sufficiently? Swpb (talk) 14:12, 22 January 2018 (UTC)
- @ArthurPSmith: Would really like your response here. Swpb (talk) 17:54, 22 February 2018 (UTC)
- @Swpb: I think "corresponding" really isn't sufficient to clarify these relationships - A surrounds B, A orbits B, A is in same font and size as B are quite different types of relations. I'd possibly support a qualifier that specifies context or constraints somehow - "relationship = xxx"? I can see there's a potential purpose for this sort of property, so I don't oppose its creation at this point, but I still don't think we have quite the right model for handling it here. ArthurPSmith (talk) 18:33, 22 February 2018 (UTC)
- @Swpb: Ok, I think my problem is that there's a context assumption missing in all these. An urban heat island is hotter than the *surrounding* rural area, bu it's not hotter than every possible rural area. A satellite is less massive than *the primary body it orbits*, but there can certainly be primary bodies that are less massive than a given satellite (e.g. Pluto is less massive than Earth's Moon, and many other moons in the solar system, but is primary body for its own moons). An "em-dash" is longer than an "en-dash" in a given font, but certainly not across differing fonts or even the same font set at different sizes. I'm concerned that these proposed properties will lead to incorrect inferences unless we can also somehow specify the context they are valid for. I'm not sure how to do that though. ArthurPSmith (talk) 16:55, 11 January 2018 (UTC)
- I'm really not sure I understand how abstraction is a problem; it's actually the point. Yes, these are classes of items; as you say, instances would have specific numerical values, and would not need this property. LZ 129 Hindenburg (Q217964) was a specific aerostat (Q1299477) with a specific density (Q29539) that could be given numerically. But aerostat (Q1299477) as a class does not have a specific density – what can be said about the density of aerostats in general is that it will always be less than that of air, by definition. Satellites can have very different masses, but they will always, by definition, be less massive than the bodies they circle; otherwise they are not satellites. These inequality relationships are central to the identity of the items, but right now there is no satisfactory way to express them. A complete definition of an item almost always requires several statements; sometimes one of those statements is that the item is larger, higher, deeper, etc. than another particular item, but not by a particular amount; that ought to be captured. Swpb (talk) 17:41, 10 January 2018 (UTC)
- @Swpb: I think I'm bothered by all your examples being abstract. I'm not sure what the real implied meaning is, it seems a little too ambiguous. For concrete wikidata items, it seems to me you would just have the property set for each item, for example length (P2043), and then one object being greater or less than another is a simple matter of comparing numbers, there's no need for a wikidata property for it. In general how is one to pick the two items being compared? You suggest it's somehow part of the definition of one item vs the other, but I think if what you want is to better define an item via structured data we should look at all that goes into definining it (and the comparison object in cases like these). But maybe something like this is needed; still thinking about it... ArthurPSmith (talk) 17:19, 10 January 2018 (UTC)
- Is it that it's too obvious, so why doesn't it exist already? That was my first thought, but I can't think of any reason it shouldn't exist. If your concern is about these being used for trivial statements, the names or descriptions can make explicit that the item must be defined as having a greater or lesser value than the object. Or, if you're concerned about which part is the main statement and which is the qualifier, that can be turned around (at the risk of leaving a meaningless statement if the qualifier is missing): urban heat island (Q215712)greater thanrural area (Q175185)
Oppose. I think the quantities you want to compare should be added on the items themselves: then you can do the comparison yourself. The generalization to patterns like the ones you suggest in the examples seem too blurry to me. − Pintoch (talk) 15:36, 22 February 2018 (UTC)
- @Pintoch: Your objection is based on a complete misunderstanding of the use case. As discussed thoroughly above, the items in question don't have specific numerical values: the information is relative rather than absolute, but there's nothing "blurry" about it – the statements could not be more clear in their meaning. I'd invite you to examine the above discussion more carefully, or perhaps at all, before you comment. Swpb (talk) 17:51, 22 February 2018 (UTC)
- @Swpb: sorry, I should have made my point clearer indeed. Here is what I mean. I think that we should not add statements like urban heat island (Q215712)has characteristic (P1552)temperature (Q11466)
greater thanrural area (Q175185) because they are imprecise: maybe some urban heat island in Russia is colder than some rural area in Sudan. This is what I meant by "blurry". I would be in favour of adding temperature statements, not on urban heat island (Q215712) or rural area (Q175185) (because indeed they do not have a temperature themselves), but on concrete urban heat islands and concrete rural areas (so, different items than the ones you want to add statements on). Then you can make queries on that and compare actual values. More generally I guess I just do not see the point of using this property in the first place, because the cases where it genuinely holds universally will be quite tautological. The scope just seems too broad for me: should we also state that the core of a diesel engine is hotter than a drinks vending machine? But maybe you have a particular use case in mind that I am not aware of? A SPARQL query that you want to do, an infobox that you want to fill with that? Maybe there is a way to restrict the property to a narrower domain. − Pintoch (talk) 17:45, 18 March 2018 (UTC) - @Pintoch: The "problem" you describe of comparing Russia and Sudan was also already addressed, with the word "corresponding", which you don't seem to be aware of. That also moots your comment about diesel engines and soda machines, which obviously do not have corresponding instances. And there is nothing close to a tautology in any of the example statements: it's not "tautological" to state a definition – it's a necessity. You can stand by your oppose, but your case would be bolstered by some demonstration of, again, having read the discussion. Swpb (talk) 14:39, 19 March 2018 (UTC)
- @Swpb: I am sorry that you seem to be taking my oppose vote as a personal attack - that was not my intention at all. I find your notion of corresponding instances too vague. What are the corresponding instances of aerostat (Q1299477) and air (Q7391292)? It's the air that the aerostat is floating in. That's quite different from the notion of correspondence for em-dash and en-dash (which would be… to be written in the same font, I guess?). May I ask you again what is your own motivation to get this property created? I have the impression that your effort to generalize its scope (which is always laudable) has obfuscated your real need. There could be a way to make this property more precise if we narrow it down to the field that you are interested in. − Pintoch (talk) 15:02, 19 March 2018 (UTC)
- I don't consider it an attack, but it does show disrespect for my time when it appears you aren't aware of what's already been said. My motivation is that every simple fact expressible in natural language should be expressible in data statements, and right now there are a huge swath of simple facts where this is not the case. If you don't already know that an aerostat is lighter than air, or that an en dash is shorter than an em dash, the Wikidata items cannot tell you these basic things, and that is a failure. No one talks about "narrowing the scope" of instance of (P31) – some properties are wide because they need to be. There's absolutely no reason the "correspondence" relationship needs to be the same in every instance, only that it be obvious from context; and in all the examples, the "corresponding instance" is the most obvious possible one. For an aerostat, it's the air that that aerostat interacts with, not some other one. For a satellite, it's the primary body of that satellite, not some other one. For items of the same type, like dashes, the only justifiable assumption to make a comparison meaningful is ceteris paribus (Q572079) – "all else being equal" – so yes, that would mean font and font size. These assumptions don't rely on any cultural factors, or anything else that would lead to different interpretation. If there were a realistic issue of ambiguity – e.g., if it were really plausible that we'd be comparing an en dash in a book to am em dash on a sign without saying so – we'd have a problem. But there isn't, so we don't. Swpb (talk) 15:26, 19 March 2018 (UTC)
- +If, for some reason, it is unclear what relation "corresponding" means, there is the qualifier criterion used (P1013):
- @Swpb: I am sorry that you seem to be taking my oppose vote as a personal attack - that was not my intention at all. I find your notion of corresponding instances too vague. What are the corresponding instances of aerostat (Q1299477) and air (Q7391292)? It's the air that the aerostat is floating in. That's quite different from the notion of correspondence for em-dash and en-dash (which would be… to be written in the same font, I guess?). May I ask you again what is your own motivation to get this property created? I have the impression that your effort to generalize its scope (which is always laudable) has obfuscated your real need. There could be a way to make this property more precise if we narrow it down to the field that you are interested in. − Pintoch (talk) 15:02, 19 March 2018 (UTC)
- @Pintoch: The "problem" you describe of comparing Russia and Sudan was also already addressed, with the word "corresponding", which you don't seem to be aware of. That also moots your comment about diesel engines and soda machines, which obviously do not have corresponding instances. And there is nothing close to a tautology in any of the example statements: it's not "tautological" to state a definition – it's a necessity. You can stand by your oppose, but your case would be bolstered by some demonstration of, again, having read the discussion. Swpb (talk) 14:39, 19 March 2018 (UTC)
- @Swpb: sorry, I should have made my point clearer indeed. Here is what I mean. I think that we should not add statements like urban heat island (Q215712)has characteristic (P1552)temperature (Q11466)
- @Pintoch: Your objection is based on a complete misunderstanding of the use case. As discussed thoroughly above, the items in question don't have specific numerical values: the information is relative rather than absolute, but there's nothing "blurry" about it – the statements could not be more clear in their meaning. I'd invite you to examine the above discussion more carefully, or perhaps at all, before you comment. Swpb (talk) 17:51, 22 February 2018 (UTC)
- * urban heat island (Q215712)has characteristic (P1552)temperature (Q11466)
greater thanrural area (Q175185) {{{7}}} criterion used (P1013) = proximity (Q19267375) - * aerostat (Q1299477)has characteristic (P1552)density (Q29539)
less thanair (Q7391292) criterion used (P1013) = proximity (Q19267375) or interaction (Q52948) - * satellite (Q1297322)has characteristic (P1552)mass (Q11423)
less thanprimary body (Q7243056) criterion used (P1013) = interaction (Q52948) - * em dash (Q10941604)has characteristic (P1552)length (Q36253)
greater thanen dash (Q13219273) criterion used (P1013) = ceteris paribus (Q572079) - I don't see a need to make that qualifier mandatory, but I'd be ok with it if it got the property created. Swpb (talk) 15:44, 19 March 2018 (UTC)
- My motivation is that every simple fact expressible in natural language should be expressible in data statements. there we go, this is where we disagree: I think there are plenty of things that you can state in natural language and which just do not fit well enough in the Wikibase data model to be included in Wikidata. Because a property needs to be used in a uniform way across many items in order to be useful, and this is less likely to happen if the property is too convoluted or ambiguous. − Pintoch (talk) 16:25, 19 March 2018 (UTC)
- @Pintoch: Well first, I think you're disagreeing not just with me, but with one of fundamental precepts of the project. We're not talking about opinions or anything squishy – these are hard, indisputable facts that can easily be expressed. The items are conspicuously incomplete without them; there is no good reason to just give them up. But more importantly, you have not shown that this property is "too convoluted or ambiguous", especially in light of the possible qualifier (which you haven't addressed). Saying repeatedly isn't showing: you have yet to show a single plausible misinterpretation. Swpb (talk) 17:14, 19 March 2018 (UTC)
- @Swpb: well, if I disagree with a fundamental precept of the project, I wonder why there is no support vote here, more than two months after the proposal was started? If you really want this property to be created, my advice is to keep calm and respect the editors who take the time to comment on your proposal. Passers-by are less likely to stop over to leave a supporting comment if they see a long heated discussion. To answer your questions specifically, I think the property is ambiguous without the qualifier, and convoluted with the qualifier. But the real issue for me is that I do not see why it would be useful to have this property in the first place. Yes, there are plenty of concepts that cannot be defined in Wikidata, and that's fine, Wikidata is not Wiktionary. − Pintoch (talk) 08:48, 20 March 2018 (UTC)
- 1) "I don't see support votes" is not an argument for an "oppose" vote, or evidence about the project's aims, but you knew that; 2) I've given you as much respect as you've given me, and if there's heat here, it's all on your side; 3) If you're really saying that defining statements don't add value, well, I don't believe you believe that; and 4) I still see no example of a plausible misinterpretation from you, so again, you're saying but not showing. That's fine, but if you don't want to support your case, maybe it's time to sit back and wait for editors who do. Swpb (talk) 14:26, 20 March 2018 (UTC)
- @Swpb: well, if I disagree with a fundamental precept of the project, I wonder why there is no support vote here, more than two months after the proposal was started? If you really want this property to be created, my advice is to keep calm and respect the editors who take the time to comment on your proposal. Passers-by are less likely to stop over to leave a supporting comment if they see a long heated discussion. To answer your questions specifically, I think the property is ambiguous without the qualifier, and convoluted with the qualifier. But the real issue for me is that I do not see why it would be useful to have this property in the first place. Yes, there are plenty of concepts that cannot be defined in Wikidata, and that's fine, Wikidata is not Wiktionary. − Pintoch (talk) 08:48, 20 March 2018 (UTC)
- @Pintoch: Well first, I think you're disagreeing not just with me, but with one of fundamental precepts of the project. We're not talking about opinions or anything squishy – these are hard, indisputable facts that can easily be expressed. The items are conspicuously incomplete without them; there is no good reason to just give them up. But more importantly, you have not shown that this property is "too convoluted or ambiguous", especially in light of the possible qualifier (which you haven't addressed). Saying repeatedly isn't showing: you have yet to show a single plausible misinterpretation. Swpb (talk) 17:14, 19 March 2018 (UTC)
- My motivation is that every simple fact expressible in natural language should be expressible in data statements. there we go, this is where we disagree: I think there are plenty of things that you can state in natural language and which just do not fit well enough in the Wikibase data model to be included in Wikidata. Because a property needs to be used in a uniform way across many items in order to be useful, and this is less likely to happen if the property is too convoluted or ambiguous. − Pintoch (talk) 16:25, 19 March 2018 (UTC)
- * urban heat island (Q215712)has characteristic (P1552)temperature (Q11466)
Not done Not enough support. Micru (talk) 08:15, 4 April 2018 (UTC)