I have encountered opposite of (P461) of
Palembang (Q8131), added by Docu in 2013. This is not the intended use of opposite of (item that is in some way the opposite of this item). In short, a proposal to avoid the errors of P461.
So, I got interested in the 21000+ uses of P461. Are they all relevant? What is the opposite of a city? A non-city? I suggest "antipode" to start dusting off. I pass on the imprecision of antipodes already in WD.
Details: places can have several antipodes depending on the size of the place. Do not hesitate to correct. Cordially. —Eihel (talk) 03:35, 4 April 2021 (UTC)[reply]
Hello Joshbaumgartner The queries is only the "game corner". I made quite simple queries and WQS does not allow very elaborate queries (and surely my queries can be corrected and are perfectible, WQS is not my strong point). I am not offering a coordinate property, but an assembly of places, which is more informative for WD. The computation of an antipode requires 2 operations and a condition, which already leads to 2/3 of the limit of WQS possibilities for only items containing P461. The specialists can surely guide you better than me, but an antipode is only a small point and it is necessary to be able to check the places around on a perimeter in comparison to the starting perimeter. This implies to additionally use "radius". In short, the calculations and conditions in addition to the radius surely greatly exceed the 60 s authorized (if I add the starting perimeter which is not present in all places…). In addition, it must be assumed that the starting coordinates are centered and correct, my examples have been verified before and each contributor will have to verify these coordinates. Otherwise, I agree with you: it would be easier for everything to be done automatically . On the other hand, I think that a complex constraint could be developed for the verification of the antipodes entered in WD. Also, if you have an idea to improve this proposal, I am open to all proposals. Warmest regards. —Eihel (talk) 05:24, 4 April 2021 (UTC)[reply]
Hello Eihel Thanks for the details. If I understand you correctly, there would be an effective radius to apply to any uses, so you could have items that are not strictly antipodal by exact coordinates, but are so close as to be essentially antipodal (hence the ~60 sec tolerance). Is this what you intend for use of this property, or am I misunderstanding? I have an additional question, which I will ask separately below so it can be answered independently. Josh Baumgartner (talk) 12:27, 6 April 2021 (UTC)[reply]
Question Why is the domain artificial geographic entities? Seems like any geographic entity could have an antipodal element (such as the north and south poles). — The Erinaceous One 🦔06:14, 4 April 2021 (UTC)[reply]
Comment I would hope that this property would work for any physical object with a coordinate location on the globe. I do wonder whether the antipode item should be limited to 'like' items (i.e. for a country, only use a country as antipode; for a mountain, only use a mountain; etc.), if there is some practical range (i.e. for a mountain, another natural feature (mountain, river, etc.) is okay but not a political entity), or if anything goes (probably not the best if I was to guess). Josh Baumgartner (talk) 12:27, 6 April 2021 (UTC)[reply]
@Eihel: I see that, but my question is essentially this: If there is a mountain which is at the antipode of a city, could they be listed as antipodes of each other using this property? Josh Baumgartner (talk) 23:41, 17 April 2021 (UTC)[reply]
Comment leaning to Oppose for now. The antipod can be inferred with coordinates (with WDQS or any other tool, and BTW WDQS *does* allow very elaborate queries just not wide one), no need to store it explicitly. And I'm not sure to understand the problem with opposite of (P461) (an antipod is - by its very definition - an opposite) and it seems the imprecision problem can easily be solved by using criterion used (P1013) in qualifier (which is already given in example of the property and the most used qualifier for this property). Cdlt, VIGNERON (talk) 10:40, 4 April 2021 (UTC)[reply]
Hello VIGNERON, On your first sentence, I would reply that everything can be deduced other than data on WD, but in this case WD would be much less filled. By exaggerating in your direction, we can even do without a lot of things. I don't see why we couldn't store this information? The deduction by a request is not valid in this case. The problem with using opposite is the qualifiers used. For the control of this data (as I already explained) cannot be done if the information is embedded in P461. As the opposite term is broad, I have given several bogus examples (even with WQS). If there is an appropriate term for a concept, you might as well use it instead of accumulating errors that could clearly be ruled out with this proposition. Not everyone is a champion or may not even know WD's SPARQL, and antipodes data can be added to sister projects much more easily. Whereas, to base oneself on the opposite in order to have the antipode, is to end up with aberrations. We are far from repeating properties on images for example: it is clearly a + to have this property. When I told you about it on Discord, you seemed to agree. Cordially. —Eihel (talk) 16:15, 17 April 2021 (UTC)[reply]
@Eihel: agree to disagree. Yes, there is a lot of redundancy on Wikidata, some has been removed (a lot of genealogical properties have been deleted for instance) some is kept, this is a trade-off. Wikidata has still too much redundancy in my opinion, we should strive to be more atomic and focus on the real data (en:Database normalization applies to relational database - unlike Wikidata - but it still a good guideline for semantic data), so yes we *should* « do without a lot of things ». Redundancy is very big problem in itself (first and foremost, much more work for no additional value). No, not « everything can be deduced » (if it were true, it would mean that we would and up with only one unique data, this is obviously not true). The deduction is not made by request but by logic, SPARQL queries are just one tool (among many other, infoboxes make deducation in Lua without SPARQL for a common alternative) not deduction itself. And no, because there is some errors doesn't mean we should add more errors. I've looked on Discord, I clearly said on March 1st « this can already be calculated automatically » (which is still my position here). Cheers, VIGNERON (talk) 18:02, 17 April 2021 (UTC)[reply]
@Eihel, VIGNERON: If this property is merely a calculated result, and not a statement based on an original source which expressly states 'X is the antipode of Y', I don't see any reason why we should have it. If an item has accurate location data, and the antipode, as a mere calculation of that, doesn't offer any real value (as with any other calculations...what is 90deg west or east of it, for example). While in that case the antipode can be calculated, it is at best just a duplication of what we already have. If we do not have valid location data (either it is missing or cannot be modelled in WD), then having this property as a calculated result is even worse, as it wouldn't even be internally verifiable. If the intent of this property is to be merely a calculated result based on the location of an item, I have to oppose it at this point. Josh Baumgartner (talk) 23:41, 17 April 2021 (UTC)[reply]
Question I'll ask this separately here so it can be answered independently from my question above. You list SPARQL results as your source, but this would make for a circular reference as SPARQL gives Wikidata results. Do you have any third-party original sources that could be used for this property? On a related comment, if we are to add this property based on users' own observation and/or calculation, it would be original research, I believe. Is this intended to be a property that permits original research to be included? Josh Baumgartner (talk) 12:27, 6 April 2021 (UTC)[reply]
Hello Joshbaumgartner, It is not a source to reference the antipodes, it's not an identifier. What I put is lists of localities, because not all "lands" have antipodes. It is as if I had put the address of Google Maps as the source. Chile, Malaysia, Argentina and other Southeast Asian countries, you can see that it corresponds with the map: the localities of these territories are very likely to have antipodes. It is to be put in perspective with the approximate value of the "number of ids" field. Under the topic field, you can see "generic", so it's like writing me about sources for of (P642) or P31. Yes, WM is not a source for WM. You can find a site that offers localities or antipodal territories to other localities and territories to make a proposal for an external identifier, but it is not this proposal. Here, the errors can be removed with a complex constraint by comparison of coordinates. All the contributors' additions are not referenced (example: P31) and they are not original creations so far, it is common sense. citation needed constraint (Q54554025) is not used everywhere and by far. On the other hand, there are sites to calculate antipodes for you. Cordially. —Eihel (talk) 17:00, 17 April 2021 (UTC)[reply]
@Eihel: It is difficult to see how this would fall into the same category as instance of (P31) or subclass of (P279), which are not referenced because they are expressly used to create internal structure of classification within WD. of (P642) is a qualifier property, so does not itself require a reference (ref being added to the main property of the statement), so again, is a different type of property than this one. As I mentioned above, there are real problems with this being merely a reflection by way of calculation of an item's location. The only way I could see this property being a valuable addition to the data we already have is if it is to capture original source material statements of 'X is the antipode of Y', which would then be distinct statements and would only be applied to the exact X and Y as stated in the original source. If the intent is for this property to not be referenced, then I am afraid I cannot support it. Josh Baumgartner (talk) 23:41, 17 April 2021 (UTC)[reply]
Hello VIGNERON Ah oui. Par contre, comme je suis passablement béotien en SPARQL, si vous avez des remarques, suggestions, changements ou tout autre commentaire sur les requêtes ci-dessus, je suis preneur. Si je peux m'améliorer, c'est tout bénéf pour moi aussi. (Si vous avez le temps et l'envie, bien entendu ) —Eihel (talk) 22:56, 18 April 2021 (UTC)[reply]
Weak oppose I think an antipode property is a cool proposal in theory, but as I think about it more, it seems impractical to try to model this in Wikidata. There are a LOT of geographical items and we could add several antipode statements to each item (for instance, if a location is antipodal to Buenos Aires, you could have <place>antipodeBuenos Aires, <place>antipodeArgentina, <place>antipodeSouth America, etc). I would be open to making the property if it was only to be used on significant antipodes, but it seems like 'opposite of' is sufficient for this purpose. — The Erinaceous One 🦔10:22, 21 April 2021 (UTC)[reply]
WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. —Eihel (talk) 03:39, 4 April 2021 (UTC)
Question Can this simply be determined by calculating the antipode coordinates (based on coordinate location (P625)) and then querying all items at or encompassing that location? Josh Baumgartner (talk) 03:57, 4 April 2021 (UTC)
The queries is only the "game corner". I made quite simple queries and WQS does not allow very elaborate queries (and surely my queries can be corrected and are perfectible, WQS is not my strong point). I am not offering a coordinate property, but an assembly of places, which is more informative for WD. The computation of an antipode requires 2 operations and a condition, which already leads to 2/3 of the limit of WQS possibilities for only items containing P461. The specialists can surely guide you better than me, but an antipode is only a small point and it is necessary to be able to check the places around on a perimeter in comparison to the starting perimeter. This implies to additionally use "radius". In short, the calculations and conditions in addition to the radius surely greatly exceed the 60 s authorized (if I add the starting perimeter which is not present in all places…). In addition, it must be assumed that the starting coordinates are centered and correct, my examples have been verified before and each contributor will have to verify these coordinates. Otherwise, I agree with you: it would be easier for everything to be done automatically 
. On the other hand, I think that a complex constraint could be developed for the verification of the antipodes entered in WD. Also, if you have an idea to improve this proposal, I am open to all proposals. Warmest regards. —Eihel (talk) 05:24, 4 April 2021 (UTC)
Comment I would hope that this property would work for any physical object with a coordinate location on the globe. I do wonder whether the antipode item should be limited to 'like' items (i.e. for a country, only use a country as antipode; for a mountain, only use a mountain; etc.), if there is some practical range (i.e. for a mountain, another natural feature (mountain, river, etc.) is okay but not a political entity), or if anything goes (probably not the best if I was to guess). Josh Baumgartner (talk) 12:27, 6 April 2021 (UTC)
Oppose for now. The antipod can be inferred with coordinates (with WDQS or any other tool, and BTW WDQS *does* allow very elaborate queries just not wide one), no need to store it explicitly. And I'm not sure to understand the problem with opposite of (P461) (an antipod is - by its very definition - an opposite) and it seems the imprecision problem can easily be solved by using criterion used (P1013) in qualifier (which is already given in example of the property and the most used qualifier for this property). Cdlt, VIGNERON (talk) 10:40, 4 April 2021 (UTC)
) —Eihel (talk) 22:56, 18 April 2021 (UTC)
Weak oppose I think an antipode property is a cool proposal in theory, but as I think about it more, it seems impractical to try to model this in Wikidata. There are a LOT of geographical items and we could add several antipode statements to each item (for instance, if a location is antipodal to Buenos Aires, you could have <place>antipodeBuenos Aires, <place>antipodeArgentina, <place>antipodeSouth America, etc). I would be open to making the property if it was only to be used on significant antipodes, but it seems like 'opposite of' is sufficient for this purpose. — The Erinaceous One 🦔 10:22, 21 April 2021 (UTC)
Withdrawn —Eihel (talk) 13:38, 23 April 2021 (UTC)