Popcorndude

Welcome to Wikidata, Popcorndude!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

• Introduction – An introduction to the project.
• Wikidata tours – Interactive tutorials to show you how Wikidata works.
• Community portal – The portal for community members.
• User options – including the 'Babel' extension, to set your language preferences.
• Contents – The main help page for editing and using the site.
• Project chat – Discussions about the project.
• Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, don't hesitate to ask on Project chat. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards! Liuxinyu970226 (talk) 02:52, 25 December 2014 (UTC)

Stop removing data from claims

Hello, please stop removing data from claims like this or this. Those edits are absolutely unuseful and counterproductive.--Sevela.p (talk) 18:52, 7 April 2015 (UTC)

I have been removing them because they are constraint violations. However, now that you point it out, fixing this violation leaves the information nowhere. In future I will do my best to ensure the the data is present somewhere else before removing it. Thank you for notifying me. Popcorndude (talk) 19:11, 7 April 2015 (UTC)

Popcornbot edits

Hi, it seems that most of Popcornbot's latest batch is wrong. Actually, I do not quite get what prompted edits like [1] given that Oviedo (Q14317) is an instance of administrative division, so a valid value for located in the administrative territorial entity (P131) and a discouraged value for location (P276). -Zolo (talk) 13:21, 28 April 2015 (UTC)

located in the administrative territorial entity (P131) is for administrative divisions, and location (P276) is for physical objects, events, etc. The items being edited are all statues, so as far as I can tell, location (P276) is the correct property. This batch of edits was prompted by these items being listed as constraint violations for located in the administrative territorial entity (P131). Does that answer your question? Popcorndude (talk) 13:34, 28 April 2015 (UTC)

The property description may not be very clear, but usage has always been that located in the administrative territorial entity (P131) is when the value is an administrative division, which makes a lot more practical sense. Property talk:P131 states that value should be an administrative unit, but it does not state that the property should only be used in items that are themselves administrative unit. I do not see Q17496648 in Wikidata:Database reports/Constraint violations/P131, even though your edit was made after the latest report update. Anyhow, if this shows somewhere in an error report, the issue ls more likely about how the errors are detected than about this particular statement. --Zolo (talk) 14:17, 28 April 2015 (UTC)

Sorry, I was a bit unclear, I got it based on the type statistics, so that particular item is probably covered by "Too many results. 160700 records skipped."

The talk page of located in the administrative territorial entity (P131) says

Domain	geographical object (Q618123)

Allowed values	administrative territorial entity (Q56061): administrative areas

That is, the item must be a geographical feature (Q618123) and the property must point to a administrative territorial entity (Q56061)

statues are not geographical objects, they are a subclass of artwork, which is the domain of location (P276). Popcorndude (talk) 18:50, 28 April 2015 (UTC)

It is indeed written that the domain of P131 is geographical feature (Q618123), but this is just a guideline in the property documentation, it does not trigger constraint violation report. The constraint violation template has geographic location (Q2221906), which is wider. Beside, several of the items you edited are technically instances of geographical object. For instance Monument aux morts de l'île du Souvenir (Q17341711): {{is a|Q17341711|Q618123}} -> false. If that was useful of course, change constraint to p131 so that it rejects its use on Monument aux morts de l'île du Souvenir (Q17341711), but that sounds like a very bad idea. Also, note that this edit creates at least two constraint violations (on Mérimée ID (P380) and on heritage designation (P1435)).

Sorry, but I really think the whole bot run should be reverted. --Zolo (talk) 20:50, 28 April 2015 (UTC)

I have set the bot to reverse the previous changes and I will endeavor to be a little more careful in future. located in the administrative territorial entity (P131)'s constraint violation page stated that sculpture (Q860861)s were not accepted, so I started on them. Perhaps I will have more success with amateur football club (Q14752149)s and company (Q783794)s. Popcorndude (talk) 21:59, 28 April 2015 (UTC)

Reversion complete. Popcorndude (talk) 23:04, 28 April 2015 (UTC)

Thanks.

Actually, it is true that "statue" is not an accepted domain for P131 ("monument" is one), but P276 has the same geographic location (Q2221906) constraint. Whether we choose one or the other does not depend on the item type, just on the value type. Most P131 domain errors are likely due to an incorrect class structure, or more simply because the current domain constraint is too restrictive.

For companies, I think the location should be provided through headquarters location (P159), I don't know for football clubs - I would imagine through P159 and home venue (P115). -Zolo (talk) 07:49, 29 April 2015 (UTC)

headquarters location (P159) location (P276) says

Domain	any object or event that can be located

So it doesn't have domain errors. At least, as far as I can tell. Popcorndude (talk) 11:41, 29 April 2015 (UTC)

sorry, wrong property Popcorndude (talk) 19:35, 29 April 2015 (UTC)

Sorry, yes, I misread the constraint. Anyhow, it does not change the fact that if the value is an administrative unit, it should use P131 (ok, there may be some tricky cases, but this is already more straightforward than having to mix considerations about the domain and about the value). I have removed the constraint, as there are just too many cases where it does not work. --Zolo (talk) 20:09, 29 April 2015 (UTC)

As far as I can tell from the description and constraints P131 applies if the item the property is on is an administrative unit, rather than the item the property is pointing to. Popcorndude (talk) 22:45, 29 April 2015 (UTC)

The property name and its English description tell in clearly that the value should be an administrative unit. Should also the item on which is statement is made a property ? This not how things have been done so far. For instance, the property is used in tens of thousands of buildings, and recommended in the talk page of architect (P84), heritage designation (P1435) etc. The constraint on P131 said that the value should be an administrative unit, and only that the item where the statement is made should be a "location". Maybe we could change that, but that would mean changing tens of thousands of items, several Wikipedia templates, and possibly a dozen of constraints (and even not considering this, I do not think it would be a good idea at all). --Zolo (talk) 06:43, 30 April 2015 (UTC)

Yes, both location (P276) and located in the administrative territorial entity (P131) should point to a location, but located in the administrative territorial entity (P131) says that the item must also be a location, while location (P276) does not.

Based on the talk pages, P131 is for things like "this city is in this county", while P276 is for things like "Mona Lisa (Q12418) => musée du Louvre (Q19675)" Popcorndude (talk) 12:06, 30 April 2015 (UTC)

International relations

Where did you coordinate the bot job about the bilateral relations ?? Because me I proposed another way more than one month ago... I just applied it on several pages (most about Germany to clean up the mess of another user), using qualifiers diplomatic mission sent (P531) and participant (P710) where possible. You just removed the qualifiers. Where and with who did you decide this new way ? Louperivois (talk) 06:51, 9 June 2015 (UTC)

It's the third item on the list of property swaps on this page. I was doing it because country (P17) is supposed to be which country something is located in and participant (P710) seemed like it would then be correct. If you let me know where it messed up on this I'd be happy to fix it. Popcorndude (talk) 13:49, 9 June 2015 (UTC)

We should think to a way to keep information about the embassies and maybe the foreign ministries. In the batch I have treated, the former is a qualifier participant (P710) of country (P17) and the latter is a qualifier diplomatic mission sent (P531). If you don't erase the qualifiers for the transition this would be good. Also, the new way is violating both of the constraint violations of participant (P710). It accepts only event (Q1656682), even not occurrence (Q1190554). And it requires reciprocity. Maybe it is time to change theses rules a bit. Louperivois (talk) 15:15, 9 June 2015 (UTC)

Also I don't see anywhere that country (P17) is purely a location. The labels and descriptions are very large. Louperivois (talk) 15:23, 9 June 2015 (UTC)

Odd, I thought I had checked both properties. Anyway, the violation I was correcting was probably that country (P17) had qualifiers other than start time (P580) and end time (P582). Maybe I should just stop using this script, I can't seem to make non-controversial edits with it. :)

Anyway, participant (P710) seems like it would make more sense since you're listing the participating countries. If we add relation (Q930933) to the allowed types of participant (P710), it should cover this use case.

Just by the way, I noticed that a lot of these are listed as both international relations (Q166542) and bilateral relation (Q15221623), though the latter is a subclass of (P279) of the former, so the former should be unnecessary. Popcorndude (talk) 16:04, 9 June 2015 (UTC)

I'm going to put messages on the talk pages of this property, the project chat and the int'l relations project because the interested people should discuss and agree on this. The questions to be solvedː

• Replace country (P17) by participant (P710)?
• If so, it's imply to have relation (Q930933) in the allowed types of participant (P710). Is it accepted ?
• To store diplomatic mission sent (P531) info on the bilateral relation (Q15221623) items, either we allow it as a qualifier of country (P17), or we allow it to be used as a statement. Which option is the best ?

Louperivois (talk) 16:39, 9 June 2015 (UTC)

@Louperivois: Since no one has responded in nearly a month, is it ok if I procede? At this point I should in any case either revert the changes or finish the job. Popcorndude (talk) 21:37, 3 July 2015 (UTC)

I think you should use participant (P710) as it was intended to. Using it for countries is going against both of the constraint violations. Furthermore it is not established that country (P17) has something to see only with the location. It has a much broader usage and it should remain on the relation items. Louperivois (talk) 19:19, 8 July 2015 (UTC)

I have set the bot to work on the results of "claim[710:(claim[31:6256])] and claim[31:166542]", removing Canada–Democratic Republic of the Congo relations (Q4373995) from the list, changing participant (P710) to country (P17). Popcorndude (talk) 19:33, 8 July 2015 (UTC)

@Louperivois: I believe I have undone all the changes. I will check again to be sure when the constraints violation report updates. Popcorndude (talk) 23:41, 8 July 2015 (UTC)

has phoneme (P2587)

per your proposal
--- Jura 08:25, 5 March 2016 (UTC)

descriptions to categories

Hi Popcorndude, thanks for adding descriptions. Can you please change hy description for categories form "Վիքիպեդիա:Կատեգորիզացիա" to "Վիքիմեդիայի նախագծի կատեգորիա". I'm a native Armenian speaker and I think that this sounds more Armenian :)--ԱշոտՏՆՂ (talk) 12:16, 13 January 2017 (UTC)

I am not currently an active editor, but if I become one again I will be sure to do so. Popcorndude (talk) 12:44, 13 January 2017 (UTC)

Thanks ^_^.--ԱշոտՏՆՂ (talk) 20:17, 13 January 2017 (UTC)

Unused properties

This is a kind reminder that the following properties were created more than six months ago: has phoneme (P2587), grammatical option indicates (P2591). As of today, these properties are used on less than five items. As the proposer of these properties you probably want to change the unfortunate situation by adding a few statements to items. --Pasleim (talk) 19:26, 17 January 2017 (UTC)

Proposition of « parent language » property

Hello, I see you on Wikidata:WikiProject Linguistics. I’m french wiktionarian who want to work on languages on Wikidata. After testing some properties, I decided to propose a new propety « parent language » to link langagues as natural thing (not like construct thing with based on (P144)). I would like to have your opinion on the issue. Thanks ! Lyokoï (talk) 21:26, 19 June 2020 (UTC)