Wikidata:Project chat

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2021/10.

Is there a good reason such edits are technically even possible?Edit

[1]. This whether the page is protected or not. --- Jura 20:14, 22 September 2021 (UTC)[]

@Jura1: No she is not. If I see correctly in the side protection log, the last protection ended on February 21, 2020. --Gymnicus (talk) 20:43, 22 September 2021 (UTC)[]
Would it be possible to prevent edits like this with abuse filters? --Marsupium (talk) 09:24, 23 September 2021 (UTC)[]
Hello Marsupium It'd be up to the community to decide if they want the abuse filter to handle such changes. -Mohammed Sadat (WMDE) (talk) 11:43, 27 September 2021 (UTC)[]
@Mohammed Sadat (WMDE): what's the dev view on this ? --- Jura 10:03, 26 September 2021 (UTC)[]
Why would you prevent such edits? Changing the precision may be correct in some cases. How would you correct a wrong precision if such edits were somehow prevented? --Dipsacus fullonum (talk) 10:57, 26 September 2021 (UTC)[]

The change at Q80871#P569 is the following:

FromTo
date of birth (P569): 7 April 1889
referenced by:
  1. imported from Wikimedia project: English Wikipedia
  2. stated in, Integrated Authority File, retrieved, 9 April 2014
  3. stated in, BnF authorities, retrieved, 10 October 2015, reference URL, http://data.bnf.fr/ark:/12148/cb12020618k
  4. stated in, Encyclopædia Britannica Online, Encyclopædia Britannica Online ID, biography/Gabriela-Mistral, named as, Gabriela Mistral, retrieved, 9 October 2017
  5. stated in, SNAC, SNAC ARK ID, w67s7m92, named as, Gabriela Mistral, retrieved, 9 October 2017
  6. stated in, Find a Grave, Find A Grave memorial ID, 7611795, named as, Gabriela Mistral, retrieved, 9 October 2017
  7. stated in, Discogs, Discogs artist ID, 1001389, named as, Gabriela Mistral, retrieved, 9 October 2017
  8. stated in, Estonian biographical database, Estonian biographical database ID, 6794, named as, Lucila Godoy Alcayaga, retrieved, 9 October 2017
  9. stated in, Brockhaus Enzyklopädie, Brockhaus Enzyklopädie online ID, mistral-gabriela, named as, Gabriela Mistral, retrieved, 9 October 2017
  10. stated in, Gran Enciclopèdia Catalana, Gran Enciclopèdia Catalana ID, 0042919, named as, Gabriela Mistral
  11. stated in, GeneaStar, GeneaStar person ID, lucilademariadelperg, named as, Gabriela Mistral
  12. stated in, Babelio, Babelio author ID, 149635, named as, Gabriela Mistral
  13. stated in, Munzinger Personen, named as, Gabriela Mistral, Munzinger person ID, 00000000356, retrieved, 9 October 2017
date of birth (P569): July 1889
referenced by:
  1. imported from Wikimedia project: English Wikipedia
  2. stated in, Integrated Authority File, retrieved, 9 April 2014
  3. stated in, BnF authorities, retrieved, 10 October 2015, reference URL, http://data.bnf.fr/ark:/12148/cb12020618k
  4. stated in, Encyclopædia Britannica Online, Encyclopædia Britannica Online ID, biography/Gabriela-Mistral, named as, Gabriela Mistral, retrieved, 9 October 2017
  5. stated in, SNAC, SNAC ARK ID, w67s7m92, named as, Gabriela Mistral, retrieved, 9 October 2017
  6. stated in, Find a Grave, Find A Grave memorial ID, 7611795, named as, Gabriela Mistral, retrieved, 9 October 2017
  7. stated in, Discogs, Discogs artist ID, 1001389, named as, Gabriela Mistral, retrieved, 9 October 2017
  8. stated in, Estonian biographical database, Estonian biographical database ID, 6794, named as, Lucila Godoy Alcayaga, retrieved, 9 October 2017
  9. stated in, Brockhaus Enzyklopädie, Brockhaus Enzyklopädie online ID, mistral-gabriela, named as, Gabriela Mistral, retrieved, 9 October 2017
  10. stated in, Gran Enciclopèdia Catalana, Gran Enciclopèdia Catalana ID, 0042919, named as, Gabriela Mistral
  11. stated in, GeneaStar, GeneaStar person ID, lucilademariadelperg, named as, Gabriela Mistral
  12. stated in, Babelio, Babelio author ID, 149635, named as, Gabriela Mistral
  13. stated in, Munzinger Personen, named as, Gabriela Mistral, Munzinger person ID, 00000000356, retrieved, 9 October 2017

This has nothing to do with changing the precision of a statement. Would it ever be correct? I doubt. Maybe you have a sample. --- Jura 12:53, 26 September 2021 (UTC)[]

@Jura1 As I too understood what you wrote, this was about being able to edit a protected page ("the item wasn't actually protected"), or changing the precision dates of statements ("from the software side of things we wouldn't want to prevent people from making edits to items"): but from your last response what you're describing seem to be something else. Can you please explain what the problem is? Thanks. -Mohammed Sadat (WMDE) (talk) 11:35, 27 September 2021 (UTC)[]
The edit makes no sense (compare the two versions, including the references). Even when the page isn't protected, it shouldn't be possible.
Maybe "replacing a claim with 12 references with a different claim with the same 12 references" better describes what is being done.
One needs to bear in mind that claims should actually be based on the references attached to them.
I don't think the are cases where this type of edit can make sense.
On a side note (not that it matters to the problem discussed above): If one reference includes a date of a different precision, the sensible thing to do would be to create a new statement with that precision and move the one reference that didn't support the other precision there.
@Mohammed Sadat (WMDE): --- Jura 11:55, 27 September 2021 (UTC)[]
@Jura1: There is a phabricator regarding this issue: https://phabricator.wikimedia.org/T231728 {{Phabricator|T213630}}. Ayack (talk) 12:18, 27 September 2021 (UTC)[]
The notice already exists and seems sensible if there is just one reference. --- Jura 12:23, 27 September 2021 (UTC)[]
@Ayack: It seems you referenced two different tickets (phab:T231728 in your comment and phab:T213630 with the template outside your comment) . As the above problem isn't "tracked" in phab:T213630 either. I changed it to {{Tl}}.
FromTo
date of birth (P569): 8 January 1823
referenced by:
  1. stated in, Integrated Authority File, retrieved, 26 April 2014
  2. stated in, BnF authorities, Bibliothèque nationale de France ID, 12419995h, retrieved, 26 June 2020
  3. stated in, Encyclopædia Britannica Online, Encyclopædia Britannica Online ID, biography/Alfred-Russel-Wallace, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  4. stated in, SNAC, SNAC ARK ID, w6bc41d1, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  5. stated in, Find a Grave, Find A Grave memorial ID, 6416, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  6. stated in, Indiana Philosophy Ontology Project, InPhO ID, thinker/4085, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  7. stated in, Brockhaus Enzyklopädie, Brockhaus Enzyklopädie online ID, wallace-alfred-russel, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  8. stated in, Gran Enciclopèdia Catalana, Gran Enciclopèdia Catalana ID, 0071768, named as, Alfred Russel Wallace
  9. stated in, Croatian Encyclopedia, Hrvatska enciklopedija ID, 65781, named as, Alfred Russel Wallace
  10. stated in, The Fine Art Archive, abART person ID, 149559, reference URL, https://cs.isabart.org/person/149559, retrieved, 1 April 2021
date of birth (P569): 8 January 1822
referenced by:
  1. stated in, Integrated Authority File, retrieved, 26 April 2014
  2. stated in, BnF authorities, Bibliothèque nationale de France ID, 12419995h, retrieved, 26 June 2020
  3. stated in, Encyclopædia Britannica Online, Encyclopædia Britannica Online ID, biography/Alfred-Russel-Wallace, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  4. stated in, SNAC, SNAC ARK ID, w6bc41d1, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  5. stated in, Find a Grave, Find A Grave memorial ID, 6416, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  6. stated in, Indiana Philosophy Ontology Project, InPhO ID, thinker/4085, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  7. stated in, Brockhaus Enzyklopädie, Brockhaus Enzyklopädie online ID, wallace-alfred-russel, named as, Alfred Russel Wallace, retrieved, 9 October 2017
  8. stated in, Gran Enciclopèdia Catalana, Gran Enciclopèdia Catalana ID, 0071768, named as, Alfred Russel Wallace
  9. stated in, Croatian Encyclopedia, Hrvatska enciklopedija ID, 65781, named as, Alfred Russel Wallace
  10. stated in, The Fine Art Archive, abART person ID, 149559, reference URL, https://cs.isabart.org/person/149559, retrieved, 1 April 2021

Another sample from [2]. --- Jura 07:16, 30 September 2021 (UTC)[]

@Mohammed Sadat (WMDE): do you need more information? --- Jura 04:45, 30 September 2021 (UTC)[]
  • Seems it got archived too quickly. --- Jura 10:58, 10 October 2021 (UTC)[]
    Thanks for providing those samples, and sorry for late response, I missed the ping about it. I agree with what you wrote, such changes are indeed problematic. But as I said earlier, we generally wouldn't want to prevent people from making edits to Items. This ticket Ayack pointed partly handles the problem by showing editors the warning icon, so they may reconsider their action. From the dev side of things, we currently have no way of knowing what is in the reference, and neither does the abuse filter. Either ways, if we are to disallow such changes, it’d have to be a decision that the community makes, then we can take it from there. Would you like to open an RFC to get consensus on that? -Mohammed Sadat (WMDE) (talk) 16:36, 14 October 2021 (UTC)[]

Elo ratings updateEdit

I am ready to do it regularly:

  • Update the chess players' ratings on a monthly basis according to the FIDE monthly reports
  • Sort rating entries by date
  • Add the maximum rating value, if such a property exists. I do not know. This property is needed in the chess player's card on Wikipedia. If there is no such property, maybe create it?
  • Delete duplicate a chess player's rating if he has not played this month and his rating has not changed. Example: one participant flooded Wikidata with useless data, for example, Garry Kasparov has 201 rating entries, but the last 140 entries are the same. Why duplicate a rating if it hasn't changed since last month?
  • Add a chess player, if he is in the FIDE's sheet, regardless of his achievements. Or need clear criteria for adding. Although I do not see the need for this. The criteria are necessary for wikipedia in my opinion. But wikidata is for everyone, we don't know who might need this data.
  • Replacing the links to the member's page on the FIDE's site with a more reliable link to the monthly rating file on the FIDE's site. Member's page is deleted after death, but monthly files remain.

Please express your opinion. Игорь Темиров (talk) 17:41, 28 September 2021 (UTC)[]

@Игорь Темиров Where do you envision these monthly Elo rating to go in a ten or twenty years' time? The items of chess players will have hundreds of statements for Elo ratings. Wouldn't it be better to just move all Elo ratings to Tabular data on Commons now? Vojtěch Dostál (talk) 18:54, 28 September 2021 (UTC)[]
@Vojtěch Dostál. I have been posting the ratings of the best chess players on the commons.wikimedia.org for a year now. Used in the module:RatingFIDE for set the rating Elo to the chess player's card.
But there is a limit to the page size, accommodates about 30 thousand chess players out of 300 thousand. This is good for the current chess rating, but bad for the history of the rating change.
Apparently, Wikidata is the best option for this, but with the condition of deleting duplicate useless entries during the period when the chess player has no games. Игорь Темиров (talk) 19:41, 28 September 2021 (UTC)[]
Re: size limit - that's unfortunate. I wish there was a way to store these numerical, periodically changing data that doesn't involve Wikidata :( Vojtěch Dostál (talk) 19:49, 28 September 2021 (UTC)[]
I am now not active in the chess field, so this should only be a hint that those actually involved can exchange ideas. Regarding the duplicated posts, you could, if you want, use the two properties start time and end time. I have already done this with chart placements, which, like the chess player ranking, change from time to time. --Gymnicus (talk) 21:21, 28 September 2021 (UTC)[]
  • Do we still do ELO ratings for zombies? At some point people kept getting ELO ratings even for dates after their known date of death.
It seemed to be me that @Steak: put some order in it and updates them on a quarterly basis. Isn't this sufficient?
There is some discussion also at Wikidata_talk:WikiProject_Chess#Elo_ratings_update. --- Jura 05:56, 29 September 2021 (UTC)[]
"Duplicate ratings" is a misconception by the thread opener. A rating is not simply duplicate, when it does not change from one rating period to the next. FIDE provides Elo ratings in regular intervals (currently once per month, in former times it was e.g. twice a year), and our task is to provide this data. There is no gain in simply omitting ratings that do not change. A complete list of best ratings of current month would not be possible if players without rating change are simply left out. And yes, we also provide Elo ratings of people that are dead, when FIDE also provides this data, but these ratings are marked as deprecated. Steak (talk) 06:00, 29 September 2021 (UTC)[]
I don't think Wikidata's task is to provide nonsensical ratings. If people are interested in zombies, these should go directly to FIDE. --- Jura 06:17, 29 September 2021 (UTC)[]
I agree with Jura here. If rating value does not change over a time period, it is unnecessary to state it several times. Instead, a longer time window of start time (P580) and end time (P582) can be used to aggregate this information, without any information loss. Vojtěch Dostál (talk) 10:14, 29 September 2021 (UTC)[]
"Duplicate ratings is a misconception by the thread opener" - FIDE provides the full rating because it is its responsibility. But we don't need unchanging ratings. Игорь Темиров (talk) 15:56, 29 September 2021 (UTC)[]
Removing duplicate rating makes it hard or impossible to query lists for specific months. Can you show me how you would get the Elo Top 100 for, e.g. January 2009, if not every player has a rating statement for that month? Currently the query looks like this:
SELECT ?item ?elo ?fide_url WHERE {
  ?item wdt:P31 wd:Q5; p:P1087 [ ps:P1087 ?elo; pqv:P585/wikibase:timeValue ?time ] .
  FILTER (YEAR(?time) = 2009 && MONTH(?time) = 1) .
} ORDER BY DESC(?elo) LIMIT 100
Try it!
How would you modify it?
Next issue is with the de:Template:Elo-Diagramm: If a rating is removed, the connection line between the ratings is not anymore straight, but skewed, because the intermedia rating is missing. See e.g. de:Sergei_Alexandrowitsch_Karjakin: If all ratings between February 2020 and November 2020 would be missing, there would be a diagonal line between January 2020 and January 2021. Which would be of of course wrong. For Bent Larsen on the page de:Template:Elo-Diagramm, it is even more apparent, that the line would be wrongly diagonal if the constant ratings between January 2005 and October 2008 would be removed. Steak (talk) 16:16, 29 September 2021 (UTC)[]
  • Why do we need the top 100 Elo, for example, for January 2009?
"Which would be of of course wrong" - Not at all, the graph only shows the trend, and not the super-accurate value of the rating. Игорь Темиров (talk) 16:30, 29 September 2021 (UTC)[]
You simply don't know what people need. Why would you not need a top Elo list of a given rating period? You cannot simply say "We don't need it". Currently the possibility is there, and you want to destroy it without need. And regarding the Graph: No, if the graphs shows a line at rating 2700, when in reality the rating was 2750, then the graph is at least misleading. Steak (talk) 16:38, 29 September 2021 (UTC)[]
@Steak presumably there should be no diagonal lines, because the rating is not only merely not-everywhere-smooth but actually discontinuous. So probably interpolate: step-after is what you need somewhere in there? See https://vega.github.io/vega/examples/line-chart/ for an example. Inductiveload (talk) 16:32, 29 September 2021 (UTC)[]
Yes, maybe, I don't know how this works exactly. Steak (talk) 16:38, 29 September 2021 (UTC)[]
@Steak Specifically, with interpolate: step-after you only need a data point when the value changes, so all the intermediate points are redundant. Inductiveload (talk) 23:20, 29 September 2021 (UTC)[]
Okay, for this usecase this might be fine. Still, for ratings lists of a given month, all ratings of that month are needed. Steak (talk) 15:33, 30 September 2021 (UTC)[]
  • Actually, I don't mind the periodical updates. The frequency is IMHO debatable. I (still) find the additions after a person died problematic. I thought we had stopped with that. For some uses, I just skip chess players. Occasionally, it happens that this drops a person that is otherwise notable. --- Jura 16:31, 29 September 2021 (UTC)[]
More general   Comment, not specifically for this exact ELO thing. Would it make more sense to farm out data-series like this (and other "heavy" uses like the famous found in taxon (P703) (e.g. see (E)-p-coumaric acid (Q99374)) to farm out to a separate, dedicated item? Specific templates can follow a relevant property (e.g. probably some kind of generic "has data series", qualified as needed) to the list and then happily inhale as much as it wants from there. Meanwhile, the actual item itself is not accruing a unbounded amount of data (multiplied by the number of "heavy" items certain projects want to use).
Are people using queries that that would be impractical for? Inductiveload (talk) 16:43, 29 September 2021 (UTC)[]

shouldn't this discussion be at Wikidata:Requests for permissions/Bot? BrokenSegue (talk) 23:28, 29 September 2021 (UTC)[]

Sure, if the Thread Opener wants to do changes in big scale, he should apply for a bot. Steak (talk) 15:33, 30 September 2021 (UTC)[]

The ratings for September appeared. Summing up some of the discussion:

  • The edits are done by my bot.
  • Does not add new non-title players.
  • Sorts Elo occurrences by date without removing duplicates.
  • Adds ratings for September and the following months without duplicates.
  • Replaces the link to the FIDE's player card with the link to the regular rating list of FIDE (example, Q108360564) or olimpbase-file (Q108680205).

So good? Игорь Темиров (talk) 07:09, 2 October 2021 (UTC)[]

I don't agree to the sorting and to the last point. Sorting is not needed. If you sort without changing the statements, I actually don't care if you do it or not. But don't remove retrieval date and the FIDE-IDs in the references. They are needed. For example, take Roman Popov (Q27530047) and Roman Popov (Q27530048). If you look at an Elo list, how would you distinguish between them? In this case, you could use the DoB, but this might be missing or even be the same. The only unique identifier is the ID, and therefore it is needed for every single statement. For this usecase, it does not matter if the profile page still exists or not. Steak (talk) 13:45, 3 October 2021 (UTC)[]
Your example is useless. If we know the ID of a chess player, then we will find it in the rating list. But if his card has disappeared, then your link leads nowhere. For example, grandmasters Pal Benko (Q465247), Stanislav Bogdanovich (Q18544873), Oleg Chernikov (Q4513619), István Csom (Q874008), Gildardo García (Q11699820), Dmitry Kayumov (Q4218359), Gennady Kuzmin (Q1231236), Yrjo A. Rantanen (Q1338668), Radoslav Simic (Q4419655), Markus Stangl (Q90543), Sulava, Nenad (Q2284127), Dmitry Svetushkin (Q3774368), Miroslav Tosic (Q4461611), Predrag Trajkovic (Q4461781), Wolfgang Uhlmann (Q1510108), Arsen Yegiazarian (Q2120169). Make sure all your Elo links from these chess players are going nowhere. These are only grandmasters and only for the last two years. What to do with your links that have stopped working?! But you can still find it in the rating lists. Of course, replacing links with more reliable ones is needed. Игорь Темиров (talk) 14:38, 3 October 2021 (UTC)[]
@Игорь Темиров: Again, if you are running a bot you must make get approval on Wikidata:Requests for permissions/Bot. Looking at your history I see lots of bot edits without approval. Sorting ELO statements is not valuable. Also can you go and nominate all the non-notable items you created for deletion. Example: Q108686706. BrokenSegue (talk) 16:42, 3 October 2021 (UTC)[]
@BrokenSegue: Thanks. All this has already been discussed above. Except for deleting. A request for deletion was submitted, but did not find support. But, as I wrote above, I will not add chess players without titul in the future. Игорь Темиров (talk) 17:17, 3 October 2021 (UTC)[]
@Игорь Темиров: Can you give me a link to where request for deletion was submitted? I'm very surprised we decided to keep clearly non-notable people. BrokenSegue (talk) 17:56, 3 October 2021 (UTC)[]
@BrokenSegue: yes. Игорь Темиров (talk) 18:19, 3 October 2021 (UTC)[]
That request for deletion is still active and you are the only one opposed to deletion... BrokenSegue (talk) 18:33, 3 October 2021 (UTC)[]
This topic is not about that. Игорь Темиров (talk) 19:30, 3 October 2021 (UTC)[]

Steak wrote "How would you modify it?" I would simply add tests for start time (P580) and end time (P582). There is no problem in that, but the query will be slower because you need a filter (unlike for point in time (P585)!):

SELECT ?item ?elo
WHERE
{
  ?item wdt:P31 wd:Q5 .
  ?item p:P1087 ?elo_stm .
  ?elo_stm ps:P1087 ?elo .
  {
    ?elo_stm pq:P585 "2009-01-00T00:00:00Z"^^xsd:dateTime .
  }
  UNION
  {
    ?elo_stm pq:P580 ?start_time .
    ?elo_stm pq:P582 ?end_time .
    FILTER (?start_time <= "2009-01-00T00:00:00Z"^^xsd:dateTime &&
            "2009-01-00T00:00:00Z"^^xsd:dateTime <= ?end_time)
  }
}
ORDER BY DESC(?elo)
LIMIT 100
Try it!

The German Elo graph template could also read P580/P582. Using them gives no loss of data. --Dipsacus fullonum (talk) 21:55, 7 October 2021 (UTC)[]

I still doubt that this is useful. Let's say I want to know Magnus Carlsen rating in January 2009. Currently, I can simply query P585 = 01/01/2009. This would need to be replaced by a filter using start time and end time. This is not user friendly. Or, you can also reverse it: If want to know someones rating in June 1999, I would currently get no result, because there was not rating published. This would be totally correct! With your method, you would get some anachronistic misleading rating. Steak (talk) 18:08, 12 October 2021 (UTC)[]
And you also can't find out how many chess players have brown eyes on January 1, 2009. And who cares? We say real reasons, but you come up with useless ones. What for? Игорь Темиров (talk) 11:23, 17 October 2021 (UTC)[]

datatype for en:Coxeter–Dynkin diagram?Edit

Is it possible to create a property about Coxeter–Dynkin diagram (Q169451)? Currently, Coxeter–Dynkin diagram in English Wikipedia uses a LUA module to output multiple pictures. (like this      ) I have no idea which datatype can store that symbols.--[雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 09:53, 30 September 2021 (UTC)[]

@A2569875 I don't know about a datatype, but if there was a canonical serialisation format, you could use that (e.g. like w:SMILES) as a string.
If you have an image, you could use image (P18)the file, and then qualify with object has role (P3831)Coxeter–Dynkin diagram (Q169451)? Inductiveload (talk) 13:54, 30 September 2021 (UTC)[]
Is it possible create a datatype like Help:Data_type#Chess?--[雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 05:10, 1 October 2021 (UTC)[]
You may want to propose a new property instead of a new datatype.--GZWDer (talk) 05:33, 1 October 2021 (UTC)[]
But how? convert the node-edge graph into string?--[雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 06:24, 1 October 2021 (UTC)[]
Is there any standard way of representing these graphs as strings? If not, then using the "commons media file" is probably the best approach. — Martin (MSGJ · talk) 07:17, 1 October 2021 (UTC)[]
Asking... en:Wikipedia_talk:WikiProject_Mathematics#about_Coxeter–Dynkin_diagram, en:Talk:Coxeter–Dynkin_diagram#store_into_wikidata. Please wait. --[雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 10:10, 3 October 2021 (UTC)[]
@Tomruen:. --[雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 13:28, 10 October 2021 (UTC)[]

Creating Wikidata powered maps of all the protected monuments for a country on Wikipedia (using Kartographer)Edit

Hi all

I'd like to try and make maps for Wikipedia which show the protected buildings in each country using data from Wikidata. I think this would be really helpful for users and show the power of Wikidata in creating visualisations, also the maps for other countries should be fairly easy to create once the first one has been finished, just changing a few parameters. A couple of years ago I helped write some documentation for this at Wikidata:Map data, but don't remember much of the process. I'd like to start with Norway because I know there is a lot of data, each protected monument is listed using Kulturminne ID (P758), I would really appreciate some help thinking about creating the maps, some inital questions:

  • Is there likely to be an upper limit of the number of points I can add to a map? Will it time out like big Query service quesries?
  • Does anyone know how to make the map using Kartographer
  • If we want to make a reusable template map that can be repurposed for lots of countries, how could we make it easy to do things like centre the map correctly.

Thanks

John Cummings (talk) 10:40, 8 October 2021 (UTC)[]

If you want to add to Wikipedia a map with a point for each item based on a SPARLQ query, then... it's not possible. See phab:T188291. Ayack (talk) 10:14, 11 October 2021 (UTC)[]

Qualifiers of image (P18)Edit

Hi everybody.

I've been working on picture qualifiers. Usually, we have depicts (P180) and media legend (P2096). Buit in the case of taxons, we often have sex or gender (P21) and location (P276) (examples: Q303077#P18 and Q310387#P18).

How do you think we could indicate that the picture is a fossil, or a jaw or a scientific illustration and still, use depicts (P180) to identify the species (e.g. in a genus item)? Using another depicts (P180)?

How would you indicate the species in a butterfly genus and also indicate that it's a caterpillar (Q81825)? With two depicts (P180)?

Thanks in advance, Paucabot (talk) 16:03, 8 October 2021 (UTC)[]

I've used biological phase (P4774) in Q304358#P18, but it seems this is not the proper use of this property. Any suggestions? Paucabot (talk) 16:06, 8 October 2021 (UTC)[]
Yes, use multiple depicts (P180) qualifiers. Sometimes simple solutions are best. --Tagishsimon (talk) 11:39, 9 October 2021 (UTC)[]
And to indicate the author of a scientific illustration, would you use creator (P170) like in Q21801#P18? Paucabot (talk) 06:42, 11 October 2021 (UTC)[]

City Also Known As ListsEdit

Ok, so some of these are obviously silly rubbish ("Modern Babylon" as a specific alt name for Q84 London) and should be removed (done), some obviously need to be added ("City of Love" for Q90 Paris), and others are obviously judgment calls ("Serenissima" more properly referred to the doge & republic than to Q641 Venice although in Italian "La Serenissima" works for the city and some English speakers use that affectedly).

Are there any good policies yet for the following questions?

1st, is it fine to purge foreign lists from the English alt names? English will certainly sometimes use Italian "Firenze" or Tuscan "Fiorenza" for modern Q2044 Florence and Latin "Florentia" for its distant past but under no circumstances will it use umlauted nonlocal Emiliano "Fiuränza" or German "Florenz" as anything other than discussion of the name in those languages. But are there any specific guidelines the project has worked out for what makes sense and what doesn't?

2nd, what's going on with all the new silly "London, England"; "Paris, France"; and "Venice, Italy" alt names? Is this just an overactive editor's well meaning mistake or a deliberate policy? The information should already be obvious from the other fields and including it (besides being a redundant eyesore) means you're begging for typos like "Rome Italy" Q220 and messes like "London, United Kingdom"; "London, UK"; "Moskva, Russia"; "Moscow, Russian Federation"; "Moscow, Russian SFSR"; "Moscow, Soviet Union" (Q649); &c. Are we really going to end up with "Rome, [Every Country that's Ever Held It]"; "Jerusalem, [Every Country that's Ever Held It]"; "[Chinese City], [Every Dynasty in Chinese History]"? I get that English language learners might benefit from knowing that Americans idiosyncratically prefer to identify their own cities by state, Canadian cities by province, British cities by constituent country, and nearly every other city on Earth by country but surely that belongs in a StackExchange discussion and not spelled out and then mistakenly extended through every single city entry on Wikidata. ― LlywelynII (talk) 22:49, 9 October 2021 (UTC)[]

To the extent I understand your post - presumably you're talking about alias lists - what's going on with all the new silly "London, England" alt names, is that London may well be known, in a diversity of systems, as "London, England", and said system or someone utilising said system's data, will more easily do a string match on "London, England" than on "London". And that is what aliases are all about: findability, both for humans and for information systems. In general, the more the better, and one embarks on a pruning exercise such as the one you're contemplating, above, only in error. --Tagishsimon (talk) 23:33, 9 October 2021 (UTC)[]
To illustrate how difficult it is to decide what "Also Known As" values are relevant or not: the smilingly obvious wrong alias of "Modern Babylon" is confirmed real by the IMDB documentary called "London: The Modern Babylon". Daanvr (talk) 17:33, 10 October 2021 (UTC)[]

Idea: Improve the sitelink systemEdit

Problem: Wiki articles may cover more, less, or different things than the Wikidata item that they are linked on.

Example:

ja:清水トンネル

describes

Shimizu Tunnel (Q22329636): railway tunnel in Japan

and

Daishimizu Tunnel (Q2623189): railway tunnel in Japan

Current solution: Make a Wikipedia article covering multiple topics (Q21484471) item (Shimizu Tunnels (Q75220055)!

The problem with the current solution: If there are other languages that cover less, more, or different concepts, they will be sitelinked on different items and Wiki users will not be able to find them!

Example of problem with the current solution: en:Shimizu Tunnel shows no sitelinks to ja:清水トンネル since they are on different items!


Better solution:

  • Move all individual (enwiki, frwiki, etc.) Wiki articles over to their own item (like Wikipedia article page (Q50081413). This also means no more Wikipedia article covering multiple topics (Q21484471)).
  • Add main subject (P921) to each article item to specify what it talks about. This is necessary so that we know which articles cover which topics (even if many of them will be the same).
  • Prevent sitelinks from being added to non-article items in the future and fix the Wikidata item creation tool.
  • Fix the Languages sitelink system on Wikipedia, Wikivoyage, etc. so that it shows users articles in other languages that cover different topics, using Wikidata as a backbone.

How to fix the Languages system:

Wikipedia will run a query on Wikidata for other Wikipedia article items that have the same main subject (P921)s and parse them into a readable view that seperates the articles by topic covered.

For example with the New Vector skin including the previously-absent English sitelink:


So clearly this would take some significant work, but I think it's a necessary and good solution.

What are your thoughts as the Wikidata community before I might propose this at the Wikimedia level? Lectrician1 (talk) 16:23, 10 October 2021 (UTC)[]

To clarify: do you propose that there is one item for “Wikipedia article about Shimuzu Tunnel” (with potentially several sitelinks), or one item for “English Wikipedia article about Shimuzu Tunnel”, one for “Japanese Wikipedia article about Shimuzu Tunnel”, etc.? Lucas Werkmeister (talk) 16:33, 10 October 2021 (UTC)[]
@Lucas Werkmeister One for each language Wikipedia. Lectrician1 (talk) 16:59, 10 October 2021 (UTC)[]
The proposal does not seem to improve anything at all. At a very great cost (additional items, additional nodes in the graph) we're being invited to rely on 'main subject' searches rather than, for instance, 'part of'/'has part' searches, for no obvious benefit. Interwiki links are not improved. The whole complexity of the way in which things can be arranged and divided, so as to achieve the distinct (fundamental, atomic) non-article items of which the article-items have 'main subject' is wished away and ignored. --Tagishsimon (talk) 17:27, 10 October 2021 (UTC)[]
@Tagishsimon I'm a bit confused by your criticism.
How would you solve this problem using part of/has part (be specific)?
How does this system have no benefit? The main benefit is that users can now find sitelinks! Lectrician1 (talk) 17:47, 10 October 2021 (UTC)[]
Users already can find sitelinks. Most articles are single subject and this isn't a problem. BrokenSegue (talk) 22:21, 10 October 2021 (UTC)[]
A much simpler solution, that also removes the need for Wikipedia article covering multiple topics (Q21484471), would be to allow several sitelinks for a language version and also allow several items to have the same sitelink. I say simpler, because it's conceptually simpler, not necessarily technically simpler (I have no idea of that). Ainali (talk) 18:35, 10 October 2021 (UTC)[]
@Ainali Some problems with that approach:
  • Sitelinks with different names than the topic items they are on can confuse editors and require occasional review to see if they actually contain the topic. Also, if a page is split or merged, than someone has to remember to go back and change the topics on their items. This creates quite a mess managing multiple sitelinks on multiple items.
  • What does the "Wikidata item" link on a Wikipedia article go to when clicked if there are sitelinks for the article on multiple items?
I think my solution is very conceptually simple. Every article has an item. If you're a Wikipedia editor, just add the topics covered in the article to the item and you're done! Wikipedia and Wikidata handle the rest. Lectrician1 (talk) 18:56, 10 October 2021 (UTC)[]
  • You have the exact same problem in your proposal, right? If you have an article named "X and Y", you will probably have two main subject "X" and "Y". So it will be the exact same result for the user. Regarding merging, the merging tools should take care of that. And if you are splitting, that is usually caused by the sitelinks, so it will be natural to fix.
  • You'll need several links, and I suggest being explicit with labels rather than just writing "Wikidata item".
Well if you have an article like "History of X", if you are a Wikipedia editor, you might be tempted to add many topics. And if it were a scientific article or a book, that might be correct. And I am not sure editing regular statements are conceptually simpler than adding sitelinks since they have many more possible buttons to click. Ainali (talk) 20:05, 10 October 2021 (UTC)[]
@Ainali
"History of X" articles are not going to create a lot of links because we already have conceptual historical items that they are linked to (for example, history of India (Q133136)). With history articles, we don't need to differentiate between what is mainly described by individual sites since they all describe "the history of X". These "History of X" articles are present across Wikipedias.
However, my proposed system actually has some benefits in regards to describing and differentiating history articles.
My system can be used to create has part (P527) statements that can describe what an article talks about on a article-level (kind of like what Mapping Orphan Wikidata Entities onto Wikipedia Sections did!). You wouldn't be able to do that without dedicated article items! Relating to this, dedicated article items could be used to describe other specific things about articles in the future! Lectrician1 (talk) 20:34, 10 October 2021 (UTC)[]
The Japanese Wikipedia is a wiki with a high tolerance for combining several different concepts into the same article. This suggestion is interesting.--Afaz (talk) 00:23, 11 October 2021 (UTC)[]

Importing 18421 french accommodations into WikidataEdit

I found a dataset of 18421 records in the public domain. A week ago I came acros this LIVE Wikidata editing #55 OpenRefine episode explaining how to clean and reconcile a dataset using OpenRefine. Sinds then I put a lot of effort into cleaning and reconciling all the 18421 accommodations, including creating a wel refferenced schema.

I feel ready to click on the "import to Wikidata" button however I beleave it is common practice to have it approved. Sounds like a good idea too. How do I go about that? where do I get aproval. I found pages about bots and such but I ma not a bot :) --Daanvr (talk) 16:32, 10 October 2021 (UTC)[]

I think opinions vary on what is & what is not bot use. Write a bot, or borrow someone else's code, and you're a bot needing approval. Use QuickStatements, Wikibase-CLI or OpenRefine, and you're not so much. I presume your proposed append mechanism is OpenRefine.
The data set has good provenance, but we know nothing about how you're reconciling the data with WD's commune, department and region item coding. Nor, especially in this area, do we know how you are reconciling rows with, for instance, the presumably many thousands of French buildings which already have WD items as a result of cultural heritage listings, and which may feature in your list. It's not clear how you will ascertain that your new append is a not duplicate of an item WD already has, where simple string matching is frustrated by the diversity of ways in which objects are labelled.
My inclination, since you have raised it here, is to invite a response to the coding and reconciliation questions; and perhaps to create 5 items new items and a couple of existing item updates (for matched rows) such that feedback can be provided. Others may have other thoughts. --Tagishsimon (talk) 17:42, 10 October 2021 (UTC)[]
@Daanvr: Thank you for your work. I can't wait to see this imported! Thierry Caro (talk) 17:45, 10 October 2021 (UTC)[]
@Thierry Caro Thank you for your enthusiasm! :) Daanvr (talk) 14:29, 11 October 2021 (UTC)[]
@Tagishsimon, Where do I find "coding and reconciliation questions"? Nor Google nor looking through Wikidata helped me :/ Daanvr (talk) 14:28, 11 October 2021 (UTC)[]
@Daanvr: Coding: I was simply referring to the need to tie up the commune, department & region strings in your dataset, with their QIds on WD, such that you can add appropriate located in the administrative territorial entity (P131) and/or location (P276) statements. Reconciliation, or deduplication: not sure there's any guidance around, but the problem is plain: there may well be entries in the dataset which already have items on WD. The trick is how to spot this; will probably involve comparing the dataset with lists extracted from WD using the Query Service, so, for instance, hotels in France, campsites in France, &c. It's ideal if data is deduplicated before addition, though it's almost inevitable that some duplicates will be created, to be found & merged later. A final point I'd make is that if the data has a robust key - and I'm not sure if the column 1 sequential number is a good key, or merely an artefact of the presentation of the data - then the key might be captured, either in a new External ID property, or else the catalog (P972) property with a inventory number (P217) qualifier. --Tagishsimon (talk) 02:48, 12 October 2021 (UTC)[]

Recoin doesn't workEdit

A very useful Wikidata:Recoin tool doesn't work anymore. Can someone help, please? --Triggerhippie4 (talk) 18:13, 10 October 2021 (UTC)[]

I reported the bug on Phabricator, let's hope someone can help. It is really a useful tool :-( --Soylacarli (talk) 19:38, 10 October 2021 (UTC)[]

@Soylacarli: The issue is resolved. --Triggerhippie4 (talk) 05:23, 11 October 2021 (UTC)[]

Yes! I just saw the notification about it on Phabricator. I'm relieved, I use Recoin all day jaja. --Soylacarli (talk) 14:13, 11 October 2021 (UTC)[]

DisruptionEdit

It seems that a user is disrupting with this kind of edit. The reason is because the user wants to delete the article from WP French. The bactery gives 126'000 results on Google, and is mentioned in the journal Nature. It would be nice if someone here keeps an eye, since I might be busy. Best regards and thanks in advance -- Basile Morin (talk) 12:19, 11 October 2021 (UTC)[]

@Totodu74: why are you deleting the sitelinks for this item? It looks like vandalism. BrokenSegue (talk) 14:46, 11 October 2021 (UTC)[]
Hi BrokenSegue. I was not aware that Wikidata was now allowing to have redirects as interwiki links, hence my first edit. Take a closer look to my following reverts: they were mostly done to re-establish taxonomic statements (taxon authors, taxon synonyms, and their references) that were also wiped away by the plaintiff contributor; and I did not care much to erase useless interwikis by doing so. For some explanations in English on the back story, see en:Wikipedia talk:WikiProject Biology#Redirecting Raoultella towards Klebsiella. Cheers, Totodu74 (talk) 15:03, 11 October 2021 (UTC)[]

Wikidata weekly summary #489Edit

need Split and MergeEdit

We have Q56292759 Jacobus Jansenius [canonical name "Janssonius" at LC] and Q56006595 Jacobus Jansonius .

"Need" Split and Merge, I say because I suppose there is a some partly-automated way to repair without manually transferring data and references (including old timestamps?), nor losing more than necessary History of robots at work.

1. Q56292759 " Jacobus Jansenius " [canonical name "Janssonius" at LC] gives not so much linked data and references for JJ as the other, but may be wholly for unique person JJ.

2. Q56006595 " Jacobus Jansonius " provides more JJ data and references than the other, but mixed with George Wood (1799-1870 http://id.loc.gov/authorities/names/n85381690). At a glance, Identifier statements alone mix data for unique JJ and unique Wood.

Where this latter item contains two statements for the same identifier, both ID may be for George Wood (two pages for one person at Open Library; three URL versions now for one page at WorldCat) or there may be one valid target for each man (VIAF; CERL).

VIAF may have the two people correctly sorted, as best possible. Its page VIAF ID: 72856671 (Wood) links neither of our two pages. Its page VIAF ID: 47106861 (JJ; we give 1812154983531067860003 which redirects) links both of our two pages.

--P64 (talk) 22:31, 11 October 2021 (UTC)[]

I've merged the two items (to Jacobus Jansonius (Q56006595)), and discarded all IDs pointing to George Wood (1799-1870) who is now temporarily absent from WD. --Tagishsimon (talk) 03:09, 12 October 2021 (UTC)[]
George Wood (Q108871756) --Tagishsimon (talk) 03:28, 12 October 2021 (UTC)[]

DOI (P356)Edit

Could somebody have a look on property Property:P356? Somebody changed the constraint violation and now a point is a violation. Thx --Chris.urs-o (talk) 02:37, 13 October 2021 (UTC)[]

@Chris.urs-o: User:Ivan A. Krestinin removed some '\' escape characters from one of the format constraints a couple of weeks ago, but maybe that's not the problem you're seeing? Can you point to a case where there's a problem right now? ArthurPSmith (talk) 17:57, 13 October 2021 (UTC)[]

The Community election of Movement Charter Drafting committee is now open!Edit

Voting for the election for the members for the Movement Charter drafting committee is now open. In total, 70 Wikimedians from around the world are running for 7 seats in these elections.

Voting is open from October 12 to October 24, 2021.

The committee will consist of 15 members in total: The online communities vote for 7 members, 6 members will be selected by the Wikimedia affiliates through a parallel process, and 2 members will be appointed by the Wikimedia Foundation. The plan is to assemble the committee by November 1, 2021.

Learn about each candidate to inform your vote in the language that you prefer: <https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee/Candidates>

Learn about the Drafting Committee: <https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee>

We are piloting a voting advice application for this election. Click yourself through the tool and you will see which candidate is closest to you! Check at <https://mcdc-election-compass.toolforge.org/>

Read the full announcement: <https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee/Elections>

Go vote at SecurePoll on: <https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee/Elections>

Best, --YKo (WMF) (talk) 06:52, 13 October 2021 (UTC)[]

Older IP addressEdit

I was using an older IP address is 72.183.34.65 Time Warner Cable. When I search google and click information Wikipedia and I didn't know how should I test the sandbox. In February 2020, after 13 years, it was internet outages and it was replaced new IP Address Spectrum. No one exciting edit Wikipedia 72.176.0.0/13. Now it is replaced New IP address 47.234.128.0/17. Everyone is excited to research edit Wikipedia.

Thanks 47.234.198.142 01:14, 14 October 2021 (UTC)[]

@47.234.198.142:
Your username and this post seem designed to confuse. :) Justin0x2004 (talk) 14:11, 16 October 2021 (UTC)[]

The allowed units constraint and unit dimensionEdit

Hello.

The allowed units constraint (Q21514353) lists units allowed for a quantity-valued property and notifies an editor if a statement was entered using a unit not in that list. If the editor sees the notification then there are two possible things to do: Add the unit to the list of allowed units or consider using (or proposing) a different property.

To help editors in deciding what to do I'll give a quick explanation: A unit, say, joule per metre (Q56023789), is used to express a variety of quantities, indicated by measured physical quantity (P111). This list need not be exhaustive - there might be subclasses of any of those quantities (like radius (Q173817) being a subclass of length (Q36253)), and those can be expressed in the same unit. All quantities related to a unit in this way have something in common: They have the same value for ISQ dimension (P4020). When two units express quantities with the same dimension then those units are called compatible - they can be converted into each other and values expressed in those units can be compared. Now, for our quantity-valued properties we should try to allow only compatible units. An example: If a property initially allowed energy (Q11379) units, say, joule (Q25269) and electronvolt (Q83327), and you want to enter a value given in joule per kilogram (Q57175225), then you should rather find a different property - one that expresses specific energy (Q3023293).

I recently did a survey of properties and found 25 which violated that principle. Some were easy or slightly difficult to fix, now we are down to 17. Here are the remaining ones:

select distinct ?prop ?propLabel where {
  ?prop wikibase:propertyType wikibase:Quantity .
  ?prop p:P2302 [
    ps:P2302 wd:Q21514353 ;
    pq:P2305 / wdt:P111 / wdt:P4020 ?dim1 ;
    pq:P2305 / wdt:P111 / wdt:P4020 ?dim2 ;
  ] .
  filter (! sameTerm(?dim1, ?dim2))
  service wikibase:label { bd:serviceParam wikibase:language "en" }
}
Try it!

Feel free to have a look and see whether any of those remaining ones can be improved or split into more specific properties.

Best wishes, Toni 001 (talk) 08:22, 14 October 2021 (UTC)[]

  • @Toni 001: I don't think that anything can be done with concentration (P6274) and solubility (P2177). These two are used with so many different units that splitting it to different properties would be impractical. Also, I see that molar mass added using mass (P2067) is being deleted in some items — years ago 'molar mass' property was rejected, because of the existence of mass (P2067). It seems that 'molar mass' property should be proposed once again. Wostr (talk) 17:26, 15 October 2021 (UTC)[]

Need help with mergeEdit

Hi. I'm trying to merge Quonset State Airport into Quonset State Airport. I'm unable to do it with Special:MergeItems, receiving this error message:

Failed to merge Items, please resolve any conflicts first.

Error: Conflicting descriptions for language de.

I don't see a description in German for either of these items though. Thanks for your help. Cryptic-waveform (talk) 15:01, 14 October 2021 (UTC)[]

@Cryptic-waveform: I was able to merge them using the gadget without difficulty. Bovlb (talk) 15:57, 14 October 2021 (UTC)[]
Magic. Thanks :) Cryptic-waveform (talk) 16:38, 14 October 2021 (UTC)[]

Wikidata Class ProjectEdit

Hello, all. I am teaching a class on documentation and we are creating Wikidata items as part of the class. Students are working on items over the next 8 weeks are doing their best to create quality, notable items. I am overseeing the projects, but cannot monitor the items 24 hours a day. I am having issues with some items being deleted very quickly for not being notable. Is there any way to ensure to items are not being deleted before we have a chance to act and fill them out more fully, add references, etc. etc.? And students are creating items for local sites and figures that may look not notable at first glance if you are not aware of the overarching data goals. This is very frustrating situation for new Wikidata learners. Suggestions please. --Smallison (talk) 17:47, 14 October 2021 (UTC)[]

Adding (ideally good quality) references from the start of the process is the most likely ameliorative measure; get your reference ducks in a row before appending the item. Ensure the item has a bare minimum of expected statements, and has well-formed label and description. Absent any of these, the item will be indistinguishable from the chaff, which is deleted in vast quantities - afaik 3000–5000 item per week are pulped. Evading being deleted is part of the learning process. --Tagishsimon (talk) 18:02, 14 October 2021 (UTC)[]
Adding on to what was already said another good technique for avoiding deletion is to integrate the items into the graph database. If an item is linked to by several other items it is less likely to be deleted en masse. BrokenSegue (talk) 21:37, 14 October 2021 (UTC)[]
@Smallison: A great project for beginners is to take a political position and fill out a whole series of them. I have been taking mayors of towns I have an interest in, and doing the research to find all the historical mayors. You start by creating an entry "mayor of X" and then one by one creating entries for each mayor. I do research by writing the mayor's office and local library to see if they already have a list, I search at newspapers.com (free with your Wikimedia account). You can concatenate them with start and end dates and then create a chart showing the mayors in chronological order. See: Mayor of Somerville, New Jersey (Q106445178) and Talk:Q106445178 for the chart, you also learn how to create a hierarchy of entries Mayors of the United States > Mayors of New Jersey > Mayors of Somerset County, New Jersey. I also contact the mayor's office and the local library asking if the have public domain images of the mayors. The task is almost unlimited, there are a dozen elected/appointed positions in each town, down to dogcatcher and postmaster. --RAN (talk) 21:55, 14 October 2021 (UTC)[]

geographic region (Q82794) and territorial entity (Q1496967)Edit

Hello,

The two look very similar to me. Should they be merged? Is one a subclass of the other? --GrandEscogriffe (talk) 20:59, 14 October 2021 (UTC)[]

According to the German-language Wikipedia, geographic region (Q82794) and territorial entity (Q1496967) are two different things. I would have to take a closer look at the German-language articles to explain why this is so. But only because of the articles de:Region (Q82794) and de:Gebiet (Q1496967) you cannot merge the two data objects. --Gymnicus (talk) 21:18, 14 October 2021 (UTC)[]
I would love to hear more from a German speaker. But it seems like de:Gebiet is not so much about a specific concept, as about a word which can mean de:Region or more specific things. At this point I am in favor of disconnecting de:Gebiet from the item (and perhaps giving it an another item about the word Gebiet) and merging. --GrandEscogriffe (talk) 10:57, 15 October 2021 (UTC)[]
I have to admit that I don't understand the breakup you are aiming for. What is the point of this separation, except that the data object then has a higher number? The data object territorial entity (Q1496967) was created in 2012 for the German article de:Gebiet. Why should you change that now? If the information in the data object is incorrect, then you have to correct it, but not simply create a new data object. --Gymnicus (talk) 11:31, 15 October 2021 (UTC)[]
@GrandEscogriffe Isn't geographic region (Q82794) any defined 3D or 2D space anywhere? Eg. region of a galaxy, region in mathematics, etc Vojtěch Dostál (talk) 11:33, 15 October 2021 (UTC)[]
@Vojtěch Dostál: In the German language Wikipedia, the region is defined as follows: „Region bezeichnet in der Geographie und der Raumordnung ein anhand bestimmter Merkmale abgegrenztes Teilgebiet der Erdoberfläche.” (english: “In geography and spatial planning, a region denotes a sub-area of ​​the earth's surface that is delimited on the basis of certain characteristics.”) --Gymnicus (talk) 11:36, 15 October 2021 (UTC)[]
@Vojtěch Dostál: there is a mismatch between the descriptions of geographic region (Q82794) on one side (according to which it can be geographic, spatial or mathematical), and its placement within larger classes and the content of the wp articles on the other side (according to which it is only geographical, i.e. on earth). The descriptions of Q1496967 seem actually more fitted to what Q82794 does.
@Gymnicus: The problem that I want to solve is that about one thousand items which are clearly geographic regions get marked as instances or subclasses of territorial entity (Q1496967) instead of geographic region (Q82794). --GrandEscogriffe (talk) 13:49, 15 October 2021 (UTC)[]

Described at urlEdit

With this edit someone deleted my addition of a url for a human. They wrote "a mere mention by name is not a 'describe' ", but I believe we have always allowed that. We do not need a full biography of someone. Should the deletion be reversed? --RAN (talk) 21:42, 14 October 2021 (UTC)[]

The page found at the URL does not in any meaningful way at all describe the item's subject, and so it's a completely unsuitable value for described at URL (P973), which as a bare minimum, requires the linked page to describe the subject. Here's the full section relating to the item's subject: "For the 2011/12 season Schöneiche has budgeted 33,000 euros for the disposal of street leaves in front of private properties, says Beate Cyron, deputy head of the construction depot." In what way does that describe Beate Cyron? SMH. --Tagishsimon (talk) 21:53, 14 October 2021 (UTC)[]
If I was to write a biography of an obscure person, I would want to find every scrap of information on that person. Other than your personal animosity towards me, what makes it "completely unsuitable", how information dense is it required to be? It perfectly describes him as the "deputy head of the construction depot". --RAN (talk) 22:00, 14 October 2021 (UTC)[]
You are confusing what might legitimately be used as a reference URL (P854) for an occupation (P106) property statement, with something that describes the subject. For sure there's a continuum between the two, and though it's hard to articulate where the line is drawn, your article is not within many dustbin wagon's length of it, and on the wrong side. --Tagishsimon (talk) 22:32, 14 October 2021 (UTC)[]
Then tell me exactly how described_at_url must be used, so we can construct a bot to delete all that do not meet the requirement. We need objective rules, not subjective ones that are followed by ad hoc deletion, that is how you end up with a database skewed by selection bias. If it can't be described so that a bot can make the decision, we should not have it. --RAN (talk) 23:22, 14 October 2021 (UTC)[]
Your supposition that a bot could be written to analyse whether a page meets a rule-based set of requirements is niave or petulant, not least in the context of "though it's hard to articulate where the line is drawn". Whereas objective rules, to the extent they can be written, are doubtless desirable, we are still left with the unbridgable chasm between an incidental mention in an article about street cleaning, and a description of a person. If a single take-away will pacify you, the linked page should be substantially (i.e. mostly) about the subject and/or provide substantial (a plurality of) information about the subject. --Tagishsimon (talk) 00:07, 15 October 2021 (UTC)[]
  • So substantially=51% of the sentences, or 51% of the paragraphs, or 51% of the pages of a book, which is it? By your rule I could not use the url for a list of war dead for a WWI veteran killed in action, since they are just one name on the list. I could not use a url of a list of Holocaust victims. Would that be true? Both of these are active projects. Argue the case before us, not the person presenting the case. There is no need to call me "niave [sic] or petulant". I would love to hear other people's opinions, thank you for yours. --RAN (talk) 02:48, 15 October 2021 (UTC)[]
Yes, you're getting there. You would not use the url for a list of war dead for a WWI veteran killed in action, since they are just one name on the list. You might use that list as a reference for a claim. Meanwhile, I'm trying not to make rules. You are - still petulantly - wobbling along with "51% of the sentences, or 51% of the paragraphs, or 51% of the pages of a book, which is it?" nonsense, as if the duck test didn't exist. --Tagishsimon (talk) 03:19, 15 October 2021 (UTC)[]
Subjective "duck tests" lead to selection bias, which we should avoid, its another way of saying "I don't like it". --RAN (talk) 06:07, 15 October 2021 (UTC)[]
I don't think described at URL (P973) is appropriate here. --99of9 (talk) 06:42, 15 October 2021 (UTC)[]
gtyhg!-_=+\[ 78.190.239.206 06:41, 16 October 2021 (UTC)[]
Would that URL not be more suitable as a reference for, say, a position held (P39) statement? It seems to me that described at URL (P973) implies that the URL is specifically about the subject (i.e. if a URL were an item, it would have a main subject (P921), the value of that property being the subject). Inductiveload (talk) 11:39, 15 October 2021 (UTC)[]


  • (Someone edit conflicted this response into non-existence so here it is again) I would think it should provide more than a passing mention of the subject to count. If it just provides one or two facts then use it as a reference for those facts instead. This is always going to be subjective though. BrokenSegue (talk) 02:56, 15 October 2021 (UTC)[]

Split implausibility (Q16886573) ?Edit

Shouldn’t these be split? The sitelink is not even about the implausibility concept, it’s just a redirect. I only doubt because it exists that way for a while, although isn’t used much anyway. — 188.123.231.2 13:36, 15 October 2021 (UTC)[]

WikidataCon 2021 and sister projectsEdit

Hi all. I'm posting here as a co-curator of the 'Sister projects' track for WikidataCon 2021, which will take place online on 29-31 October 2021. The conference website is at [3].

Wikidata has been received very differently across the various Wikimedia projects - while some have welcomed it, others are very against it, and more are still talking about it. We would really like to see case studies both about how this has gone well, and where issues have been encountered. Please consider submitting a session proposal to explore the issues that you are most interested in.

You can find information about how to submit a session proposal at [4], and you can access the submission form at [5]. Please submit a session proposal through the Pretalx process so that we can review and schedule it appropriately - and make sure to mark it as a 'Sister projects' track proposal. Please note that we cannot accept a session outside of the Pretalx process. We also encourage you to submit talks to other tracks if you are interested!

Note that the deadline for submitting proposals is the 20th October - sorry for the short notice! Thanks. Mike Peel (talk) 20:03, 15 October 2021 (UTC)[]

Gadgets brokenEdit

Please anyone know how to fix editing scripts: User talk:Magnus Manske/wikidata useful.js#Stopped working and seems User:MichaelSchoenitzer/quickpresets.js too. --Infovarius (talk) 22:12, 15 October 2021 (UTC)[]

Population densityEdit

Hello friends,

Do we have a property for "Population density"? Population density is an important component of population. If we don't already have property for population density. Can we create it as a qualifier for population (Property:1082) or as a separate value? Regards. T Cells (talk) 11:40, 16 October 2021 (UTC)[]

@T_Cells: isn't it easily derived by doing population/area (which you can do in SPARQL)?
Or you might be able to use density (P2054) and make a new entity: unit that is "people per unit area." Justin0x2004 (talk) 14:06, 16 October 2021 (UTC)[]
Also volumetric number density (Q176449) is related... though you want "count per area." Justin0x2004 (talk) 14:34, 16 October 2021 (UTC)[]
It seems that we don't have such a property. We should maintain consistent units within a property, therefore we can't reuse existing population or (mass) density properties. Instead a new property could be proposed. I took the liberty to create items for the corresponding quantity (human population areal density (Q108913965)) and a unit (person per square kilometre (Q108913970)). Toni 001 (talk) 08:47, 17 October 2021 (UTC)[]
@Toni_001:
> We should maintain consistent units within a property
I don't think that is true. For example concentration (P6274) has at least a dozen different units that are allowed. Creating a new property for each distinct unit makes Wikidata less able to semantically generalize. A property proposal for human population areal density (Q108913965) would be excessively specific. e.g. What if I want to represent the population density of Danaus plexippus (Q212398) or badger (Q638105)? Do I need to go through more property proposal processes?
I think we could accommodate this request in a more general way by looking for or proposing a corresponding property of areal number density (Q108914965).
Justin0x2004 (talk) Justin0x2004 (talk) 13:16, 17 October 2021 (UTC)[]

postal codeEdit

postal code (P281) is singular (all the labels and descriptions). It is equivalent to <http://www.w3.org/2006/vcard/ns#postal-code> whose label and comment are also singular.

But it looks like we have some use of em dash to designate a range of zip codes (plural). I think the only reason for doing so is that enumerating all the postal codes for a region such as New York City (Q60) makes the web UI content take up a lot of space... and it adds more triples. But clearly if web UI content consideration and triple count wasn't a concern we would want to store each of the postal codes in a range individually.

Do we need another property called "postal code range?" It seems like a mistake to put a range in the same property that we use for single codes.

I wonder how many kludges like this (using a property intended for singular thing for a plural thing instead) we have just because we are worried about web UI content length and triple count.

cc @NM1982:

Justin0x2004 (talk) 13:52, 16 October 2021 (UTC)[]

Introducing P10000: Research Vocabularies Australia IDEdit

Research Vocabularies Australia ID (P10000) has arrived.

"Research Vocabularies Australia (Q41147961) helps you find, access, and reuse vocabularies for research." This site is part of Australian Research Data Commons (Q4824459). The property, created today by User:UWashPrincipalCataloger (Thanks!), is an identifier for a vocabulary (not necessarily Australian) in the R.V.A. database. Many of these vocabularies are themselves well known to us, and have identifier properties on Wikidata, such as Getty Thesaurus of Geographic Names ID (P1667), ANZSRC 2020 FoR ID (P8529), and Australian Faunal Directory ID (P6039). My hope is that we may find more databases in their growing set that we in turn may use as useful properties. If you would like to help matching this catalogue, head over to (brilliant tool) Mix'n'Match set 4770.

This milestone arrived after a week of 42 property approvals, and there are plenty more to discuss in the pipeline. (15 of those proposed in the last week are Australia-related, because I was angling at hooking this milestone! Amongst those, I think R.V.A. is perhaps the most appropriate meta-vocabulary-data for a celebration of our project.)

I'm a particular fan of identifier properties, because they make Wikidata the backbone of the authority control network. They also expand the utility of Entity Explosion, a free browser extension I built to showcase and make use of Wikidata external links. So I've been keen for a long time on making sure all high-quality online databases in my country have properties and Mix'n'Match sets, and use a properties-by-country dashboard to keep track of how each country is going (using the brilliant integraality). If you're interested in proposing a property about your speciality, your interests, or your location, please don't hesitate. The template is intimidating at first, but you can always view the source of other proposals, and other users will come to your aid anyway. If you're already an experienced user, especially if you are scraping or regex-savvy, I'd suggest challenging yourself by setting up a Mix'n'Match set for a property that doesn't yet have one.

Congratulations to the community on jointly building the amazing project that is Wikidata. --99of9 (talk) 03:31, 17 October 2021 (UTC)[]