User talk:Xtextexte
Welcome to Wikidata, Monsieurbecker!
Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike, and you can help. Go to any item page now and add to this ever-growing database!
Need some help getting started? Here are some pages you can familarise yourself with:
- Wikidata:About - About the project.
- Wikidata:Introduction - Another introduction to the project.
- Help:Contents - The main help portal for editing and using the site.
- Wikidata:Project chat - Discussions about the project.
If you have any questions, please ask me on my talk page. 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.
- Regards, --Jitrixis (talk | support my candidacy) 13:40, 1 November 2012 (UTC)
One of your pages
[edit]I deleted the page that you made, Q8784, because there wasn't any content there and it had gone a while with that. If you still wanted to have something there, I can restore it, or you could make another page. Regards, Ajraddatz (talk) 21:17, 2 November 2012 (UTC)
Hi, I don't think we need an item about the "agglomeration" or "urban area" of Brussels, it has no legal meaning in Belgium (anymore), unless you use it for fr:Agglomération bruxelloise. Why did you make it? All the links just point to "Brussels", which is usually the City of Brussels. SPQRobin (talk) 21:32, 2 November 2012 (UTC)
- Hi, in my opinion, there are three reasons for this third Brussels' item:
- In the German Wikipedia, we have three different articles for Brussels: one for the City of Brussels, one for the Capital region and one for the urban area.
- I took a look at other Wikipedias and found out that most articles named "Brussels" (in the respective language) actually don't deal exclusively with the City of Brussels (about 140 000 inhabitants) but with the urban area (+ 1 mio). In some languages, this article includes informations about the region, in other languages you'll find a separate article for the region. So, we face the situation that many Wikipedias don't distinguish consistently between the city (= capital of Belgium), the urban area and the region. This leads to problems with inter-wiki links. If you analyse several links, you'll notice remarkable inconsistencies. I think that articles about the City of Brussels should only be interlinked to articles about the City, the same for the region. Due to the concept of Wikidata, you cannot add an article about both the City and region to both items.
- In the future, statistic data will be added to Wikidata. There is a big difference if you'll find in a article about the city the data for the city, the urban area or the region.
- The dewiki article on Brussels (which is contested btw) describes both the city and the region, there is no such thing as an urban area. What would be the statistics for the "urban area"? Where do you draw the line? An article is either about the city or the region, only in exceptions like on dewiki it combines both. I do know that many articles are supposedly about the city but then give data about the Region. It is in my opinion not because some Wikipedias use wrong data on a city or region article, that Wikidata should perpetuate this confusion. Many articles listed uner Q9005 can be listed under the city or region item, the "urban area" item should be used as a last resort for cases like the dewiki article, i.e. those that really cannot be classified under either the city or region. Would you agree? SPQRobin (talk) 18:56, 3 November 2012 (UTC)
- For example, the Catalan article ca:Brusseŀles is currently in the urban area item, while it can clearly be classified as being about the city. The Italian article it:Bruxelles can indeed stay in that item because it uses a similar structure like on dewiki (although it wrongly combines city and region data!). I was not aware many Wikipedias had three articles on Brussels and many of them use confusing or wrong data. SPQRobin (talk) 19:02, 3 November 2012 (UTC)
- ca:Brusseŀles is now in Q239. I understand your concerns about the term "urban area", but I don't know a better term. --Monsieurbecker (talk) 19:10, 3 November 2012 (UTC)
- Thank you for updating the label translations. I hope the emphasis on combination will avoid confusion for other users. I am now checking the links to see which ones I can transfer to the city or region items. SPQRobin (talk) 19:44, 3 November 2012 (UTC)
- Perfect. Thank you! --Monsieurbecker (talk) 19:48, 3 November 2012 (UTC)
- Thank you for updating the label translations. I hope the emphasis on combination will avoid confusion for other users. I am now checking the links to see which ones I can transfer to the city or region items. SPQRobin (talk) 19:44, 3 November 2012 (UTC)
- ca:Brusseŀles is now in Q239. I understand your concerns about the term "urban area", but I don't know a better term. --Monsieurbecker (talk) 19:10, 3 November 2012 (UTC)
- For example, the Catalan article ca:Brusseŀles is currently in the urban area item, while it can clearly be classified as being about the city. The Italian article it:Bruxelles can indeed stay in that item because it uses a similar structure like on dewiki (although it wrongly combines city and region data!). I was not aware many Wikipedias had three articles on Brussels and many of them use confusing or wrong data. SPQRobin (talk) 19:02, 3 November 2012 (UTC)
- The dewiki article on Brussels (which is contested btw) describes both the city and the region, there is no such thing as an urban area. What would be the statistics for the "urban area"? Where do you draw the line? An article is either about the city or the region, only in exceptions like on dewiki it combines both. I do know that many articles are supposedly about the city but then give data about the Region. It is in my opinion not because some Wikipedias use wrong data on a city or region article, that Wikidata should perpetuate this confusion. Many articles listed uner Q9005 can be listed under the city or region item, the "urban area" item should be used as a last resort for cases like the dewiki article, i.e. those that really cannot be classified under either the city or region. Would you agree? SPQRobin (talk) 18:56, 3 November 2012 (UTC)
Brussels
[edit]Yes, I see the problem, but the descriptions in Q9005 are not appropriate; for example «pour des articles qui combinent des informations sur la Ville de Bruxelles (capitale belge) et la Région Bruxelles-Capitale» does not follow the guidelines in Help:Description. It needs to say whether the item is about a city, a region or both (alors, pas de «pour des articles qui combinent des informations sur», mais plutôt "ville et région de la Belgique"). Could you please explained to me or fix the items' descriptions to illustrate their differences? For start, which one is considered "capital of Belgium"? Andreasm háblame / just talk to me 13:58, 22 March 2013 (UTC)
- I have modified the description of Q9005, I hope it's clear now. The city of Brussels Q239 is the capital of Belgium. --Monsieurbecker (talk) 19:58, 22 March 2013 (UTC)
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.
Littledogboy (talk) 23:01, 1 September 2013 (UTC)
INSEE code
[edit]Hi Monsieurbecker. I saw you created a new property INSEE code, which generally is fine. But this two points:
- The guidelines tells, that you should copy the proposal discussion to the property discussion. You didn't so, but I did it now. Please remember this point you create the next time a property.
- Why didn't you take the more appropriate data type 'number' instead of 'string'? I know 'number' isn't available yet, but it would be worth to wait on it. The most advantage is, that somebody who tries to stores 'wrong' values with alphabetic characters will get an error and isn't able to store his entry. This could prevent a.) unwittingly mistypes (e.g. "35839B"), b.) wittingly comments (e.g. "534534 (formerly 352662 till 2006*)"), c.) wittingly vandalism (e.g. "municipality full of dumb peoples"). * = for this case it should be used qualifiers, not a comment in the value field.
So my suggest is, you request for a deletion of your own property (the deletion process will be quickened if you're requesting it than someone else) and wait till numbers are available. As Lydia Pintscher said, data type numbers would be the next data type to be realized within some weeks. What do you think? --Nightwish62 (talk) 09:05, 31 March 2013 (UTC)
- Hi, I've put a comment on Property talk:P374 (I don't know if it's the best place, don't hesitate to correct me). I agree with Nightwish62, It would be better to restrict it to the number type. Cdlt, VIGNERON (talk) 15:17, 31 March 2013 (UTC)
- It's easy to justify the choice of 'string': Currently, 'number' doesn't exist and I didn't know that it will be created soon. If I'd known about it earlier, I wouldn't have created the property now. By the way, I really don't understand why 'number' hasn't been created yet. There are soooo many properties with numeric values, for example Property:P227 (GND), Property:P213 (ISNI), Property:P245 (ULAN), Property:P214 (VIAF), Property:P269 (SUDOC), Property:P349 (NDL), Property:P212 (ISBN), Property:P236 (ISSN), Property:P243 (OCCN), Property:P299 (ISO 3166-1 numeric). Do we have to replace all these properties because of a new data type? I don't think that this is a desirable solution. There should be a possibility to change the data type. --Monsieurbecker (talk) 17:47, 31 March 2013 (UTC)
- Yeah, I thought that's your reason. However, assign a wrong data types is bad in any way. It's easier to wait and start right than clean up later, in my opinion. You're right, the properties you've listed have the same problem. However, on the other sides there are multiple cases where the proposal was already approved, but are waiting for the necessary datatype, see here. Unfortunately, I didn't find the statement when numbers will be realized anymore. I just find two statements of Lydia Pintscher, one More data types are the next thing on the todo list and one The most likely order is currently: numbers, geocoordinates.... Perhaps I'm wrong that this would be in the next few weeks. And you're right, I also confused why this datatype takes so long, as it's pretty similar to the string datatype. So we've two choices: Start with 'string' and later change it (manually or via bot) or delete the property right now and put the property to the pending page also. I prefer the second one as to play fair with the others who are also waiting for the number datatype. Second reason: At moment we will only loose about 3-5 entries, but it's possible someone start collecting INSEE code tomorrow e.g. and it would be much more work to transfer it to the INSEE (number) later. As far as I know there isn't any bot yet which can do that job. --Nightwish62 (talk) 18:25, 31 March 2013 (UTC)
- Two things just came into my mind why the data type cannot be numeric (I'm sorry I didn't thought abouth them earlier): (1) All values must have 5 digits, some of them have a leading zero (like 06088 for Nice). I'm not sure if this is possible with a numeric value. (2) But most important: The Corsican departements have a letter in their code: 2A and 2B, so do the municipality codes: 2A004 for Ajaccio and 2B033 Bastia. Unless we cannot specify the datatype like in XML Schema, we unfortunately have to use 'string'. --Monsieurbecker (talk) 20:59, 31 March 2013 (UTC)
- Ok, the second one is good. Please notice this fact in the discussion site of the property. Thanks. --Nightwish62 (talk) 21:44, 31 March 2013 (UTC)
- Ah the Corse… Too bad.
- In facts, it's the same for some other code at least ISSNs and ISBNs (which could include the letter X in last position).
- Cdlt, VIGNERON (talk) 08:19, 3 April 2013 (UTC)
- Ok, the second one is good. Please notice this fact in the discussion site of the property. Thanks. --Nightwish62 (talk) 21:44, 31 March 2013 (UTC)
- Two things just came into my mind why the data type cannot be numeric (I'm sorry I didn't thought abouth them earlier): (1) All values must have 5 digits, some of them have a leading zero (like 06088 for Nice). I'm not sure if this is possible with a numeric value. (2) But most important: The Corsican departements have a letter in their code: 2A and 2B, so do the municipality codes: 2A004 for Ajaccio and 2B033 Bastia. Unless we cannot specify the datatype like in XML Schema, we unfortunately have to use 'string'. --Monsieurbecker (talk) 20:59, 31 March 2013 (UTC)
- Yeah, I thought that's your reason. However, assign a wrong data types is bad in any way. It's easier to wait and start right than clean up later, in my opinion. You're right, the properties you've listed have the same problem. However, on the other sides there are multiple cases where the proposal was already approved, but are waiting for the necessary datatype, see here. Unfortunately, I didn't find the statement when numbers will be realized anymore. I just find two statements of Lydia Pintscher, one More data types are the next thing on the todo list and one The most likely order is currently: numbers, geocoordinates.... Perhaps I'm wrong that this would be in the next few weeks. And you're right, I also confused why this datatype takes so long, as it's pretty similar to the string datatype. So we've two choices: Start with 'string' and later change it (manually or via bot) or delete the property right now and put the property to the pending page also. I prefer the second one as to play fair with the others who are also waiting for the number datatype. Second reason: At moment we will only loose about 3-5 entries, but it's possible someone start collecting INSEE code tomorrow e.g. and it would be much more work to transfer it to the INSEE (number) later. As far as I know there isn't any bot yet which can do that job. --Nightwish62 (talk) 18:25, 31 March 2013 (UTC)
- It's easy to justify the choice of 'string': Currently, 'number' doesn't exist and I didn't know that it will be created soon. If I'd known about it earlier, I wouldn't have created the property now. By the way, I really don't understand why 'number' hasn't been created yet. There are soooo many properties with numeric values, for example Property:P227 (GND), Property:P213 (ISNI), Property:P245 (ULAN), Property:P214 (VIAF), Property:P269 (SUDOC), Property:P349 (NDL), Property:P212 (ISBN), Property:P236 (ISSN), Property:P243 (OCCN), Property:P299 (ISO 3166-1 numeric). Do we have to replace all these properties because of a new data type? I don't think that this is a desirable solution. There should be a possibility to change the data type. --Monsieurbecker (talk) 17:47, 31 March 2013 (UTC)
Property:P429 (dantai code)
[edit]Hi,
The above property is now available and can be used on items. I noticed you participated in its discussion. -- Docu at 17:34, 16 April 2013 (UTC)
Properties
[edit]Two properties you proposed (German Municipality Key and German District Key) have been created now. Regards,--Stevenliuyi (talk) 19:20, 19 April 2013 (UTC)
The King of Rome
[edit]Why did you remove the fact that The King of Rome (Q594) is a pigeon? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:25, 10 May 2013 (UTC)
- I've removed this information because "Main type (GND)" is the wrong property. This property only allows one of seven predefined values, "pigeon" is none of them as you can see in Property_talk:P107. I've added now Property:P31. --Monsieurbecker (talk) 11:04, 10 May 2013 (UTC)
Checks
[edit]Cool! Curious what it will do on 297. -- Docu at 17:01, 20 May 2013 (UTC)
Q8908 - Query concerning gender-neutral title in the French version of the Wikidata entry on the Council of Europe
[edit]Hello MonsieurBecker, It looks like you may have been the creator of Q8908 on the Council of Europe - thank you for this! However, we are trying to modify a title on the French version of the page so that it can apply to a woman ("Présidente") as well as a man ("President"), and we seem unable to do it - could you help? More details of our query here...
https://www.wikidata.org/wiki/Talk:Q8908
With thanks in advance for any help you can provide. GAKM (15/02/2019)