Wikidata:Project chat/Archive/2022/04

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.


Stating multiple maximum capacity values based on room setup

My colleagues and I are working on the batch upload of a dataset of performing arts venues. This particular dataset is quite rich. Among other things, it stores multiple room capacity values depending on whether a given room is setup for a standing audience (no chairs), cabaret style, sitting, etc. What would be the best way to represent this information in Wikidata? maximum capacity (P1083) is subject to a single-value constraint (Q19474404) constraint, but a separator qualifier can be used to allow multiple values to be stated. Of all possible separators for maximum capacity (P1083), the only one that could be used to describe a room configuration/setup is criterion used (P1013).

  • Would it be ontologically correct and meaningful to add multiple maximum capacity (P1083) values with qualifiers such as: criterion used (P1013)standing (Q1986098) and criterion used (P1013)sitting (Q1144593)?
  • Or would it not be wiser to create a dedicated property to describe room configurations?

Fjjulien (talk) 17:28, 25 March 2022 (UTC)

Or don't record it. It seems to be extremely detailed. I would just record the maximum and nothing more. Multichill (talk) 17:42, 25 March 2022 (UTC)
I would use the qualifier applies to part (P518) Germartin1 (talk) 03:14, 26 March 2022 (UTC)
@Multichill: @Germartin1: Thanks for your input. After further exploration of the dataset, we found that the typology for room configuration uses labels that can be interpreted by users both as a room configuration and as a room type (for example, Italian theater (Q18225059) is an architectural style, not a room configuration). Because of this data reliability/accuracy issue, we decided to only load the maximum capacity for a given room. This being said, the discussion with the database manager enabled us to further define use cases that would benefit from information on capacity according to room configuration. These include rental clients such as show producers/promoters, as well as ticketing providers and arts goers. Further discussions will be needed among participants in the WikiProject Cultural venues to determine if and how room configuration and their capacities should be represented in Wikidata. I will make sure to document any update under this talk page topic. Fjjulien (talk) 21:19, 1 April 2022 (UTC)

Organizer and Sponsor properties do not include events in their constraints

I wanted to say a particular science fiction club ran a science fiction convention. Now science fiction convention (Q1958056)} is a subclass of event (Q1656682), but the latter is not a valid constraint of organizer (P664). Shouldn't events be added to the organizer constraints? (sponsor (P859) has a similar issue) Vicarage (talk) 08:32, 1 April 2022 (UTC)

Event is a subclass of occurrance. The constraint is P31/P279 of occurrence. So no. --Tagishsimon (talk) 10:20, 1 April 2022 (UTC)
I'm new to this but organizer (P664) has value type constraints of "organization, human, fictional organization, group of humans, social movement, position", and the editor certainly objects when I try to "add statement" for an event, listing these options as the only valid ones. Vicarage (talk) 10:27, 1 April 2022 (UTC)
Perhaps I'm interpreting this wrong, but I'd say FIFA organized the World Cup, or The Motion Picture Acadmey held the Oscars, what is the property to add to the former to refer to the latter? Vicarage (talk) 10:41, 1 April 2022 (UTC)
The value-type constraint and the type constraint do different things. In the context of thinking about adding event to either of the constraints, it would be added to the type constraint not the value-type. But as noted, it should not be needed. The value-type constraint says, use P664 only to point to items which are humans, organisations, etc. The type constraint says use P664 only on items that are occurences &c.
I think where it's all going wrong, in Oxford University Speculative Fiction Group (Q111446976) is that you are trying to point the organisation at the event using P31 and a P279 qualifier. That's not the right way to do it, 1) for reasons of convention - WD does not use P31 like that and 2) b/c the P279 qualifier is meaningless in that context. It is enough to do as you have done on Conine (Q111446988) and point the event at the organiser. Not all properties come in reciprocal pairs, and P664 is one of them; there is no "organiser of" property. (There is an Inverse Label Item, but that's not a property, just what the property would be called were there one.) --Tagishsimon (talk) 11:05, 1 April 2022 (UTC)
I was experimenting with P31, it certainly looks wrong. I'm surprised that looking at lots of governing bodies on Wikidata that you don't have direct links to the events they are best known for. Perhaps there is a query logic that can invert the relationship, but it feels clumsy. For the moment I will use significant event (P793), which seems good enough. Thanks for your help. Vicarage (talk) 11:18, 1 April 2022 (UTC)
Significant event is not a good choice. The broad reason WD does not list all of the things an organisation organises, on the organisation item, is that the list could easily run into thousands of items - think about FIFA and the number of football matches they've organised. Far more sensible to add organiser information to the event - where, normally, there will be a single organiser value per item. The bigger point is, WD is linked data. One should not expect all of the representation of an entity - such as FIFA - to be found on the FIFA item. Much of it may be contained on other items - football event items - that point to the FIFA item. Trying to shoehorn a pointer from your Oxford group to their event is, basically, wrong. Sorry to break that news to you, but there we go. --Tagishsimon (talk) 11:31, 1 April 2022 (UTC)

Help clean mess (New York subway)

Anyone good on language help clean the mixup between S (Q126678) and 42nd Street Shuttle (Q126698) ? Bouzinac 💬●✒️●💛 11:37, 1 April 2022 (UTC)

Unclear, from a quick look at the sitelinks, where you think the problem lies - I presume that is what you allude to by 'language help'. I think perhaps Q126678#P31 is wrong ... S does not seem to be a service so much as a service classification (shuttle) which applies currently to three discrete services. --Tagishsimon (talk) 11:42, 1 April 2022 (UTC)
Hi, I meant various wikis are not speaking about same stuff when dealing about S (some disambiguation page, some S shuttle as a service, some S as a subway line...)
There is disambiguations needed with many S shuttle services inside NYC subway.... Bouzinac 💬●✒️●💛 12:37, 1 April 2022 (UTC)

Adding Internet Archive links to the publications associated with events

Science fiction conventions like many events come with publications: progress reports, programmes, souvenir books etc. So I've been planning to create Internet Archive ID (P724) entries for the events, containing pdfs of the documents. Only I get a warning when adding Internet Archive ID (P724) to a convention which is a subclass of event (Q1656682), as event does not match any of the type constraints for the Internet Archive. Many events have associated documents, whether they be proceedings (Q1143604) for academic conferences or programme (Q1508646) for plays. Should Internet Archive ID (P724) be broadened to include event (Q1656682), or should event (Q1656682) have a publication (Q732577) property. Adding a new identifier for the "Publications from MagiCon" seems overkill. Vicarage (talk) 14:05, 1 April 2022 (UTC)

Mangaroa Stream

Maybe I'm wrong, but I think that there are about twenty times the same pages, all just about the same subject. All pages have the same text, only the coordinates differ. All of them were created by this weird Cebuano bot. I am convinced that 20 of them have to be deleted. Thanks and have a great day! Nistok1811 (talk) 18:07, 1 April 2022 (UTC) 

1. ; 2. ; 3. ; 4. ; 5. ;6. ; 7. ; 8. ; 9. ; 10. ; 11. ; 12. ; 13. ; 14. ; 15. ; 16. ; 17. ; 18. ; 19. ; 20. ; 21. ;
Apparently "Mangaroa" translates into English as "long stream." There will probably be a lot of minor water courses in New Zealand with that name. I have no idea why someone at cebwiki created a separate article for each stream, but we need a separate item for each cebwiki article. From Hill To Shore (talk) 19:20, 1 April 2022 (UTC)
Cebwiki seems largely bot-written, based on Geonames.org data. As in the case of the first of these, "Mangaroa Stream (suba sa Wellington, lat -40,62, long 175,60)" the coordinate data is in degrees & minutes, and omits seconds. So they can all be a couple of km from the object they supposedly mark. I've recently checked 1773 Scottish geonames coordinates and find that 2.83% of them were accurate, 17.6% were close but not well-centered and 79.5% of them were plain inaccurate - stats.
We can be absolutely confident that none of the above items has accurate coordinates; confident too that the elevation above sea level (P2044) data in the items relates to the bogus coordinate rather than to the stream. It's really unfortunate that, because of the geoname imports, much of WD's landform item data is bullshit. --Tagishsimon (talk) 02:23, 3 April 2022 (UTC)

vandalism on an entry

Hello. There is a person's name where it shouldn't be. The entry is about a category. Kindly see Q8666784, and look for "Khwaja Baig". I tried to remove it, but I couldn't. I think I do not have authorisation to edit that particular part/section. Kindly look into it. Regards, —usernamekiran(talk) 11:11, 4 April 2022 (UTC)

found, and fixed the issue. Apparently it was the "English description". —usernamekiran (talk) 11:15, 4 April 2022 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Matěj Suchánek (talk) 09:47, 8 April 2022 (UTC)

Can someone merge Q100982390 into Q111368650?

Can someone with more experience than me merge Q100982390 into Q111368650. They are the same person, and their English Wikipedia pages were today merged. Steelkamp (talk) 06:54, 5 April 2022 (UTC)

I merged them :) Dajasj (talk) 07:05, 5 April 2022 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Matěj Suchánek (talk) 09:47, 8 April 2022 (UTC)

Tracking down Wikivoyage's Sync of Coordinates to Wikidata reference bugs and preventing future issues

I recently identified an issue with Wikivoyage's visual editor tool for their template listings which offers the option to "sync with Wikidata" and has a user select which direction to sync which statement. There appears to be a bug in how it handles syncing to Wikidata statements which have references. I raised this issue in the EN Wikivoyage Travelers Pub. I don't know the extent of this, but am curious if anyone has ideas on how best to track down the statements. The "sync with Wikidata" editor doesn't provide a reference nor identifies the Wikivoyage sync tool use in the edit comment. Looking at the coordinate reference in this example, the automated edit doesn't appear to cause the reference to be flagged that the value changed with the reference was not being updated. Additionally no source statement of reference from Wikidata was added to aid in this identification nor source of the statement.

1. How might one identify this data issue once the Wikivoyage template is corrected?

2. Why didn't the reference get flagged when the value changed?

3. What might we do to be more resilient to bugs from tools for editing going forward? Wolfgang8741 (talk) 18:42, 30 March 2022 (UTC)

This section title should probably be titled Wikidata statements are being corrupted when the coords are synced to a Wikidata statement with a reference by Wikivoyage's Listing Editor (default template editor) to better reflect this issue undermining the data integrity of statements with references and hopefully grab someone's attention. I came across this long time issue after inspecting a sync of coordinates from Wikivoyage to Wikidata. I would like someone's help in devising a strategy to track down all issues created by the EN Wikivoyage Listing editor. I haven't looked as Javascript is not my language, but possibly other data syncing behaviors from the WV Listing Editor may have similar data integrity issues. Wolfgang8741 (talk) 03:49, 3 April 2022 (UTC)

Merger of Q23907747 to Q605714

These two are more or less duplicates for the same entity. I therefore tried to merge to the latter but didn't succeed due to the following error: "Conflicting descriptions for language ru." Can somebody help out?--Hildeoc (talk) 14:11, 1 April 2022 (UTC)

These appear to be different concepts and must not be merged. One is a geographical region and the other is a coal field. Merging these would be equivalent to saying the London Underground tube network should be merged with the city of London. They happen to share the same space but they are different things. From Hill To Shore (talk) 14:55, 1 April 2022 (UTC)
@From Hill To Shore: Sorry, but you're mistaken here. 1) Look at the EB article I linked above, which clearly states that the Donets [Coal] Basin and the Donbas are one and the same thing. Thus, those are not two distinct concepts. 2) Look at the lemmas of the various Wikipedia entries at Q23907747, and use a translator: More or less 99 % of them simply mean "Donets Basin", which – as can be seem from the said article, for instance – is simply a synonym for Donbas (cf. also e. g. the intro of the corresponding English article, which the current entry at this WD item redirects to: "The word Donbas is a portmanteau formed from "Donets Basin", an abbreviation of "Donets Coal Basin".") See also the talk page for Donets Coal Basin. BTW, AFAIK, redirects shouldn't be used as WD main entries anyway. Hildeoc (talk) 23:39, 1 April 2022 (UTC)
A coal field is not a geographic region. If the Wikipedia articles are linked to the wrong item then they should be moved to the correct location. Merging two concepts on Wikidata to simplify the management of Wikipedia sites is the wrong action. From Hill To Shore (talk) 23:51, 1 April 2022 (UTC)
@From Hill To Shore: Before we continue discussing, please do prove that "the Wikipedia articles are linked to the wrong item" first – i. e. that both items refer to different concepts, as you claim – by giving appropriate reference. Hildeoc (talk) 23:58, 1 April 2022 (UTC)
Getting stampy footed will not help the situation, Hildeoc. Whichever way you slice it, a coal basin is not the same thing as a historic region of a country. Even if they're contiguous - which I doubt - they're still not the same thing. They should not be merged. --Tagishsimon (talk) 00:11, 2 April 2022 (UTC)
@Tagishsimon: I'm sorry, but defying ignorance really has nothing to do with "getting stampy footed". To make it clear: yes, in this case, the "coal basin" is [identical with] the "region"! To give another exemplary reference, please have a look at the relevant article in the Internet Encyclopedia of Ukraine: "Donets Basin (Донецький вугільний басейн; Donetskyi vuhilnyi basein; also known as the Donets Coal Basin, Донбас; Donbas, or Donets region)." Want another one? Here you go: "The Donets Basin is a major coal-mining district in eastern Ukraine and adjacent portions of Russia. It comprises the Donbas Foldbelt, which is the uplifted and compressionally deformed part of the Pripyat–Dniepr–Donets (PDD) Basin, and the significantly less deformed Western Donbas region." Tell me if you need more ... Hildeoc (talk) 00:50, 2 April 2022 (UTC)
@Igel B TyMaHe: Would you, as the creator of the item to be merged, like to comment?--Hildeoc (talk) 00:54, 2 April 2022 (UTC)
Q605714 is the geological feature (coal reserve), Q605714 is the geographical feature (region). Why to merge? Wikipedia article can be the same for both, Wikidata items differ. Igel B TyMaHe (talk) 20:58, 2 April 2022 (UTC)
@Igel B TyMaHe: I think this would be an artificial and rather illogical distinction. Can you provide any reference for that specific differentiation of yours? In any case, regarding the articles targeted by the current entries at Q23907747, probably all of them should be moved to the former item, still. Hildeoc (talk) 00:50, 3 April 2022 (UTC)
PS: The only description at Q23907747 (in German) would translate into: "Hard coal and industrial area on Ukrainian and Russian territory".--Hildeoc (talk) 00:58, 2 April 2022 (UTC)
If you hate coal basins (geological landforms) being distinguished from historical, cultural, and economic regions (aftefacts of human civilisation), you'll simply detest all of these; items linked by coextensive with (P3403): https://w.wiki/4$nG ... imagine; Australia the continent being considered different from Australia the country. --Tagishsimon (talk) 12:12, 3 April 2022 (UTC)

Leadership Development Working Group: Reminder to apply by 10 April 2022

You can find this message translated into additional languages on Meta-wiki.
More languages • Please help translate to your language

Hello everyone,

The Community Development team at the Wikimedia Foundation is supporting the creation of a global, community-driven Leadership Development Working Group. The purpose of the working group is to advise leadership development work. Feedback was collected in February 2022 and a summary of the feedback is on Meta-wiki. The application period to join the Working Group is now open and is closing soon on April 10, 2022. Please review the information about the working group, share with community members who might be interested, and apply if you are interested.

Thank you,

From the Community Development team

IMO company number

As IMO ship number (P458) now is pointing to the IMO website, the URL is only for ship search. As shipping companies also have IMO numbers, they point to non-existing URLs. Maybe it's better to create IMO company number as a separate property? --Cavernia (talk) 11:26, 2 April 2022 (UTC)

Well the English label (and probably most others) makes it clear that this property is specifically for ships, not for companies. Therefore I suggest not to misuse the property for other things unless there is a discussion/consensus on widening the scope. Proposing a new property might be the best way to go. — Martin (MSGJ · talk) 20:26, 2 April 2022 (UTC)
The description and the documentation on the talk page make it clear that this is not just for ships, but also for ship owners and management companies (element must contain property “instance of (P31)” with classes “watercraft (Q1229765), business (Q4830453), commission (Q63705303)” or their subclasses). A problem resolving URLs doesn't call for a new property. --Jonas kork (talk) 07:20, 4 April 2022 (UTC)

Creating an artist entry

Hi! I'm new to wikidata and wikis in general and I would like to create an entry for my band to improve our online presence. I was only planning to add the official identifiers for music sites as I have seen in most artist pages, but the documentation on data donation suggested I should consult with the community what data to import. Also, are there any special guidelines I should be aware of or any documentation I should read? Any help is greatly appreciated!

Jotamunz (talk) 04:37, 4 April 2022 (UTC)

@Jotamunz: Welcome! You might find encounter some pushback here if your motivation is primarily "to improve our online presence". The essay "How to create an item on Wikidata so that it won't get deleted" might be useful to you. Bovlb (talk) 16:03, 4 April 2022 (UTC)

Queries using multiple graphs

Looking for places to train and learn about queries that use federation as well as multiple graphs. I've been experimenting a bit writing a query that federates data from DBpedia, but I was hoping some of you might know about public SPARQL endpoints that have multiple graphs that I can use for learning and training purposes. Other related resources is also of interest.

I was also wondering if graphs has to be located on the local server or at least be be directly available to the query engine. Does graph mean that you're accessing a triple-store directly, where federation means you are accessing data via an external SPARQL endpoint. Infrastruktur (talk) 10:52, 4 April 2022 (UTC)

Just unpacked the binaries for Apache Jena so that I can experiment with its Arq tool. I see it has some options for loading in various graphs from turtle files. So I could experiment locally if I had suitable datasets. Infrastruktur (talk) 16:04, 4 April 2022 (UTC)

  • @Infrastruktur: I'm not aware of public SPARQL endpoints with multiple graphs; I found a good book on SPARQL (including discussion of multiple graphs) is "Learning SPARQL" by Bob DuCharme - http://www.learningsparql.com . Generally when you are running a graph db with a SPARQL frontend it will only look at the triples stored locally; federation is what allows you to talk to other SPARQL endpoints. ArthurPSmith (talk) 17:07, 4 April 2022 (UTC)

Wikidata weekly summary #514

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • New requests for permissions/Bot: APSbot 4: Task/s: Regularly create organizations from the Research Organization Registry (ROR - https://ror.org/) that are missing in Wikidata.
  • Tool of the week
    • Kyrksok.se is an app about Swedish churches based on Wikidata.
    • QAnswer is a question answering system based on Wikidata and other projects. Who was the first to create liquid helium? Try it!
  • Development
    • Lexicographical data: Continued work on the new Special:NewLexeme page and focused on displaying sensible error messages if an error occurs during Lexeme creation. We're also working on adding a dropdown for the language variant.
    • REST API: Continued work on conditional requests and authorization
    • Made use of the new fields added in the wbsearchentities API and added language information to the markup of entity searches that you see when editing a statement or searching with the little searchbox at the top of the page on Wikidata. Now these search results should make a bit more sense to people who use screen readers.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Adding labels and aliases in unlisted languages

How does one add a label and/or an alias in a language that isn't included in the 'All entered languages'? I can't see any way of adding these for a language that isn't already listed. Thanks! - MPF (talk) 17:58, 2 April 2022 (UTC)

Please see Wikidata:Userboxes#Babel. If you set this template according to your language abilities then you should be able to access those languages in the interface. — Martin (MSGJ · talk) 20:28, 2 April 2022 (UTC)
@MSGJ: Thanks! - MPF (talk) 20:58, 2 April 2022 (UTC)
You can also use Special:SetLabelDescriptionAliases. --Quesotiotyo (talk) 21:02, 2 April 2022 (UTC)
@Quesotiotyo: Excellent, thanks! That one actually works (MSGJ's suggestion didn't!) - MPF (talk) 21:10, 2 April 2022 (UTC)
You can also switch between languages in the top right menue which also includes your notifications, watchlist etc. (You can also change the language setting in your preferences, but the shortcut is handy.) The current language is always available in the label box. Depending on how many different languages you want to add, this may be a clumsy method, though. --Jonas kork (talk) 07:09, 4 April 2022 (UTC)
You can also use the labelLister gadget.--GZWDer (talk) 20:36, 5 April 2022 (UTC)

Distributed by Netflix

In terms of movies and some TV shows, "distributor" and "distributed by" have very specific meanings, as described in the article en:film distributor. For a film, the "distributor" has historically been a film studio or similar company that sells the film first to theaters and later to TV networks and streaming services. This is usually an important part of data for indiviual movies. Unfortunately, some people ran a bunch of bots to infer distributed by (P750) values based on whether the object had identifiers for various streaming services, which greatly diluted the meaning of this property. Now every movie with a Netflix identifier is also "distributed by Netflix" and most music albums that are available digitally are "distributed by iTunes". This has been discussed at Property talk:P750, but deserves greater attention.

One example of what this has created: Of the 826 articles on Swedish Wikipedia that the Wikidata film infobox, about half are "distributed by Netflix", including a bunch of classics stretching back over a century. This is probably a cascade result of P750 being sloppily defined in the past.

If we want to track every streaming service that has ever hosted a film, show or album, it is better done with a specific property, say "made available by streaming service", similar to broadcast by (P3301). If the community wants to keep P750 as a broad catch-all property, a new property should be created for the more specific definition. As it currently stands, with various kinds of "distributors" intermingled without distinctions, distributed by (P750) is broken. Väsk (talk) 13:09, 4 April 2022 (UTC)

  • I agree with you, it should only contain projects exclusive to Netflix. For instance House of Cards was produced by Sony Pictures Television with exclusive USA distribution by Netflix. The correct information is in the Wikipedia infoboxes. All others should just have a Netflix_ID. Most streaming contracts are for a year, and there are almost a dozen streaming outlets, so the info would be out of date all the time. If people want to see where it is currently streaming there are sites like https://www.justwatch.com/us --RAN (talk) 16:07, 4 April 2022 (UTC)
House of Cards (Q3330940) is probably a bit of a special case. Netflix acted as original broadcaster (P449), but the series appears to be owned by MRC (Q2856187) who have appointed Sony Pictures Television (Q652390) as its distributor.[1][2][3] My understanding is that Netflix typically has the distribution rights for series that were commissioned later on. Merely licensing a work for "distributing" to consumers doesn't make you its distributor in the way the term is typically applied to movies and TV. Väsk (talk) 08:11, 5 April 2022 (UTC)
I'm coming from the music side and could not agree more, "distributed by" and "distribution format" lost all meaning after bots got in the game and add it to anything and everything with a streaming service identifier, without as much as a "start time" qualifier. Strong support for separating this out into a dedicated set of streaming properties, if indeed needed at all (at lot can be inferred simply by looking at the identifiers themselves). Moebeus (talk) 11:24, 5 April 2022 (UTC)
  • In video-game world, it’s less problematic as “distributor” is historically less of a thing, but I would agree a dedicated property could make things much clearer (eg, it is often remarked upon how Flashback (Q1001925) got « distributed by U.S. Gold (Q1930918) − which is generally captured by publisher (P123), not by distributed by). In VG world, a “streaming” property would not work (not completely at least ;) − I think the distinction is really between the applicable domain: an organisation (eg US Gold, or indeed Netflix when netflix-the-company produces a movie) vs a platform/storefront − think iTunes, Netflix, GOG.com, etc. Lines can be blurred indeed (Netflix steams movies and produces some ; Humble store sells games and produces some etc.), which is why a dedicated property could make sense. Jean-Fred (talk) 15:22, 5 April 2022 (UTC)
  • Actually − wouldn’t content deliverer (P3274) work for that? Jean-Fred (talk) 15:23, 5 April 2022 (UTC)

DeltaBot's coordinate location (P625) to headquarters location (P159) move

(Previous discussion; cc Sdkb, Multichill, and Pasleim)

It looks like this removal of a job that was decided to be problematic was never actually set to be reverted, which has left many edits like this with headquarters location (P159) being used instead of coordinate location (P625) still live. Does DeltaBot, or another automated tool, have a capability to mass-undo this set of edits? It seems to me that the changes made are still problematic, with the last revision linked not even making sense to use P159, semantics or not.

There's also the issue with erroneously populating en:Category:Coordinates not on Wikidata due to en:Template:coord only checking for P625 (which perhaps could also be changed to have P159 and related properties as a fall through property to use). Perryprog (talk) 14:04, 4 April 2022 (UTC)

I don't agree with your evaluation of the discussion linked. The prevailing complaint was that the change was not adequately announced, which may be true, but I don't think that is a reason for a mass revert. I routinely change coordinates to qualifiers of P159 myself, no revert of one single bot job will be able fix this. My alternative solution is to distribute notification to all Wikimedia sites that this change is about to happen, and then complete it, so that all institutions with headquarters location (P159) use coordinates as qualifiers. Currently 20,000 items with P159 have P625 as main statement, while 52,000 correctly use them as qualifiers. Vojtěch Dostál (talk) 05:17, 5 April 2022 (UTC)
Note that there is an established consensus to store coordinate location (P625) as qualifiers of headquarters location (P159) (see for example Wikidata:WikiProject Companies/Properties for companies), which is also expressed in linked templates on wikis.--Jklamo (talk) 08:13, 5 April 2022 (UTC)
I wasn't aware there was a consensus to use coordinate location (P625) as a qualifier for headquarters location (P159)—that's great to hear, and it sounds to me like it'd just be best to update enwiki's coord module to expect some form of P159 as a potential source for location. Perryprog (talk) 16:06, 5 April 2022 (UTC)

How to record references for labels?

for example, i just added Göran Aijmer (Q5544621)'s chinese labels based on https://home.uni-leipzig.de/clartp/ChineseNamesWesternScholars.html . i believe it's best to record this reference so that there wont be questions on the reliability of the chinese labels (which are not transliterations). RZuo (talk) 13:42, 5 April 2022 (UTC)

Help with query, Stardust disappear ?

Hello, I try to list space probes, but the itemLabel "Stardust" does not appear in the result.

On the other hand, when I add ps:P31 in my query, I find a statement item with itemLabel "statement/q205747-6ddb590e-493f-0e2b-6b67-c51de7424a81" which belongs to Stardust (ID Q205747).

Here is the query : 

 PREFIX schema: <http://schema.org/> 
 PREFIX skos: <http://www.w3.org/2004/02/skos/core#> 
 PREFIX wikibase: <http://wikiba.se/ontology#>
 PREFIX bd: <http://www.bigdata.com/rdf#>
 SELECT 
   ?item     # la vraie requête qui va bien
   ?itemLabel
 WHERE 
 {       
   {?item ?prop wd:Q26529} # space probe
   .
   FILTER ( 
     ?prop = wdt:P31 #instance of
     || ?prop = ps:P31 #instance of
     || ?prop = pq:P31 #instance of
     || ?prop = wdt:P2670 #instance has part(s) of the class
   )
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
 } 
 GROUP BY ?item ?itemLabel

If I search an another space probe (ex: Hayabusa2 (Q2113134)) : I find an item with itemLabel (Hayabusa2) in the query's result. I also find "statement/Q2113134-d6083885-42a9-46ff-fae9-669364d5c962" when searching for ps:P31.


There may be other cases like this one example.

How can I find itemLabel "Stardust" using "Space probe" ?

The problem here is that some bright spark has elevated one of the P31 statements on Stardust (Q205747) to preferred rank. Your query finds a ps:P31 value pointing at wd:Q26529, but thinks the ?item value is the p:P31 value - wds:q205747-6ddb590e-493f-0e2b-6b67-c51de7424a81 - rather than the wd:Qnnn value of Q205747.
I'm not quite sure what your intention with parts of the class was - as a P31 value or a P31 qualifier, so covering both bases, I'd perhaps convert your query as follows. Whether any P31 is qualified with P2670 I doubt, but have not checked.
Maybe Wikidata:Request a query is a better place for questions about queries, in future.
SELECT 
   ?item     # la vraie requête qui va bien
   ?itemLabel
 WHERE 
 {       
   ?item p:P31 ?stat . 
  {?stat ps:P31 wd:Q26529 .} # space probe
  UNION
  {?item wdt:P2670 wd:Q26529 .} #item has part(s) of the class
  UNION
  {?stat pq:P2670 wd:Q26529 .} #instance value has qualifier of has part(s) of the class
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
 } 
 GROUP BY ?item ?itemLabel
Try it!
--Tagishsimon (talk) 11:23, 1 April 2022 (UTC)
I changed the rank of the mentioned P31 statement to normal rank. The used preferred rank seemed strange to me, and not according to Help:Ranking. --Dipsacus fullonum (talk) 05:14, 6 April 2022 (UTC)

Results from the Universal Code of Conduct Enforcement guidelines ratification vote

You can find this message translated into additional languages on Meta-wiki.
More languages • Please help translate to your language

Hello all,

We would like to thank the over 2,300 Wikimedians who participated in the recently concluded community vote on the Enforcement Guidelines for the Universal Code of Conduct (UCoC). At this time, the volunteer scrutinizing group has completed the review of the accuracy of the vote and the final results are available on Meta-wiki. A quick summary can be found below:

  • 58.6% Yes, 41.4% No
  • Contributors from 128 home wikis participated in the vote
  • Over thirty languages were supported in the ballot

What this outcome means is that there is enough support for the Board to review the document. It does not mean that the Enforcement Guidelines are automatically complete.

From here, the project team will collate and summarize the comments provided in the voting process, and publish them on Meta-wiki. The Enforcement Guidelines will be submitted to the Board of Trustees for their consideration. The Board will review input given during the vote, and examine whether there are aspects of the Guidelines that need further refinement. If so, these comments, and the input provided through Meta-wiki and other community conversations, will provide a good starting point for revising the Guidelines to meet the needs expressed by communities in the voter's responses.

In the event the Board moves forward with ratification, the UCoC project team will begin supporting specific proposals in the Guidelines. Some of these proposals include working with community members to form the U4C Building Committee, starting consultations on training, and supporting conversations on improving our reporting systems. There is still a lot to be done, but we will be able to move into the next phase of this work.

Many people took part in making sure the policy and the enforcement guidelines work for our communities. We will continue to collaboratively work on the details of the strong proposals outlined in the Guidelines as presented by the Wikimedians who engaged with the project in different ways over the last year.

Once again, we thank everyone who participated in the ratification of the Enforcement Guidelines.

For more information regarding the results, please refer to the Results page.

Regards,

User:SNg (WMF)

Stella Ng on behalf of the UCoC Project Team

Senior Manager, Trust and Safety Policy -- 04:39, 6 April 2022 (UTC)

I would like to thank you for all of those who participate in the UCoC Ratification process :)--YKo (WMF) (talk) 04:39, 6 April 2022 (UTC)

How to tag the spheres of the Atomium

The Atomium has different named spheres for example the base sphere is called the François Englert Sphere but I don't know how I should tag them. Any ideas?

Jhowie Nitnek 08:31, 7 April 2022 (UTC)

I would suggest creating an item for each sphere and then using named after (P138). Ayack (talk) 14:40, 7 April 2022 (UTC)
@Ayack I was more talking about "instance of" Jhowie Nitnek 14:49, 7 April 2022 (UTC)
@Joeykentin instance of (P31): building component (Q19603939)? Ayack (talk) 07:47, 8 April 2022 (UTC)

Cross-Wiki spam: Adi Agashé aka Aditya Agashe

Can someone please check the entries around Adi Agashé (Q27922197)? Upcoming Indian singer in 2017 created a short biography, copied in 15 language versions:

2021 start of a new career as Aditya Agashe (Q107301879), American author, marketing consultant, orator, and program manager. --Kolja21 (talk) 23:56, 7 April 2022 (UTC)

"Aditya Agashe (nacido el 10 de junio de 1997),​ conocido profesionalmente como Adi Agashé, es un cantante y compositor indio y actor de Pune, Maharashtra. Se ha desempeñado como gerente de marketing en redes sociales en Brihans Natural Products Ltd. desde 2015." (Singer and marketing manager, Spanish Wikipedia.) IP claims different from with IdRef 256360952 as source. Dubious. --Kolja21 (talk) 09:27, 8 April 2022 (UTC)
See also Wikipedia articles (sv; de) written about Chandrashekhar Agashe (Q28101716) (1888-1956) stated as "Chandrashekhar Agashe I". Chandrashekhar Agashe II = Adi Agashé, singer and marketing manager. --Kolja21 (talk) 09:44, 8 April 2022 (UTC)

Adding sub-events without creating new identifiers for each

Eastercon (Q5329928) is a convention series that has been running for 70 years, with a different name each year. I don't think the individual events justify their own identifiers, but how do I record that the 48th one was called Intervention, held in Liverpool and had Brian Aldiss, Jon Bing, Octavia Butler, Dave Langford as guests of honour.

I can create a guest of honor (P967) property with a year qualifier for each guest, ditto the location, but how do I record the individual names for each event. has part(s) (P527) would be obvious, except it requires an existing identifier. I can't find a suitable property that would accept free text. I would like a format such that a SPARQL "which events was Brian Aldiss a GoH at" returned "Intervention" easily. Vicarage (talk) 18:12, 6 April 2022 (UTC)

It would be easier to make an item for each event. WD is not short of QId numbers. Trying to cludge all of the data into a single item will always be massively suboptimal.
In a single item you might use official name (P1448) qualified with point in time (P585) for the name; and location (P276) qualified with point in time (P585) for the location. And you'll have guest of honor (P967) qualified with point in time (P585) for the GoH. Anyone wishing to query the data will have to take account of the qualifiers for each property statement, rather than (in an event per item arrangement) accounting only once for the event's date. Editing tables of 70 locations, 70 names, hundreds of GoHs in a single item is suboptimal; the UI is not designed for this, and item size bloat is (or has been) a major problem for the WD infrastructure.
I urge you to reconsider your view that you don't think the individual events justify their own identifiers; they do, and they should have. --Tagishsimon (talk) 19:45, 6 April 2022 (UTC)
I worry about notability. Deletionists do a lot of damage to Wikipedia, and while I'm certain that the 50th World SF convention and its guest list will survive, will a student convention like Picocon 23 that ran for 1 day with 100 attendees be judged not-noteable, and be removed from wikidata one day? If the only information I can give is a date, location, guest and pointer to a Fancyclopedia 3rd party wiki, is that sufficent. I can certainly automate the process, but some might baulk at 10000+ identifiers being created for something so trivial as this. Vicarage (talk) 20:01, 6 April 2022 (UTC)
The data is not more or less notable if it's all put in one item versus put into lots of items, although I grant that creating multiple items is a wee bit more visible. Wikidata's notability policy is very much less onorous than is WPs. 10000 new items is 100 conference series each running events each year for 100 years. That seems fine. I cannot speak for Picocon 23, but if it is part of a series of Picocons, then there is a valid structural notability reason for including it amongst the set of other events from that series. --Tagishsimon (talk) 20:09, 6 April 2022 (UTC)
Probably worth saying that a well-ordered set of event items tied together using e.g. part of the series (P179), follows (P155), followed by (P156) will tend to withstand deletion; deleting admins will surely note that items are part of a wider collection and understand the value of preserving the whole. --Tagishsimon (talk) 20:50, 6 April 2022 (UTC)
Yes, there are notability issues, especially if a “Fancyclopedia 3rd party wiki” is the only source. I wouldn’t consider such items notable. However, in the case Eastercon (Q5329928) one could certainly argue WD:N #3 notability – although I do have to note that the en.wp sitelink seems to have a lot of unfixed issues, so maybe it would be a good idea to fix them before creating items on Wikidata … --Emu (talk) 09:51, 8 April 2022 (UTC)
The notability arises from its 70 year lifespan, and all its guests/publications as a social history archive, and as Tagishsimon says if the Wikidata structure suggests that sub-events need to be their own identifiers, that's the way I'll go. I guess I need to see if wikidata allows partial backups to protect the information from deletionists. Vicarage (talk) 17:18, 8 April 2022 (UTC)
I have to ask: Why exactly do you ask if you already seem to know that anybody who doesn’t 100% agree with you must be a deletionist that does “a lot of damage”? --Emu (talk) 20:41, 8 April 2022 (UTC)

Countries spanning more than one continent

Af few soverign countries span more than one continent: 

SELECT ?state ?stateLabel (COUNT(?continent) AS ?contCount) (GROUP_CONCAT(?continent_label; separator=", ") AS ?continents)
WHERE
{
    ?state wdt:P31 wd:Q3624078;
      wdt:P30 ?continent.
    OPTIONAL {?continent rdfs:label ?continent_label. FILTER (LANG(?continent_label) = "en"). }
    SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
GROUP BY ?state ?stateLabel
HAVING (COUNT(?continent) > 1)
ORDER BY DESC(?contCount) ?stateLabel
Try it!

The list contains a few surprises to me:

  • France includes Antartica - why not for the other countries holding a slice?
  • Turkey includes Europe, Asia, Eurasia, but the latter is the supercontinent of the two first?
  • Indonesia includes Insular Oceania - what supports such a claim?
  • UK is missing - shouldn't Gibraltar and some caribian islands be included?
  • Spain is missing - shouldn't a couple of african areas be included?

Poul G (talk) 13:48, 8 April 2022 (UTC)

platform screen door (Q570730) on subways

Hello, is there a correct use of that item on subway stations, how to model them? Bouzinac 💬●✒️●💛 08:44, 7 April 2022 (UTC)

I made a little analysis here on English Wikiversity Wikidata/Q570730-CurrentUsage which I hope might be of use. If you have any feedback for me please provide it. Even a 'thank you' or a "this is not an analysis" comments is still feedback. Thanks for bringing this subject up. There are many items on Wikidata of which there could be better documentation on how to add them in a reliable and consistent way. Maskingself (talk) 06:17, 11 April 2022 (UTC)

Can these be merged?

Can these be merged?

https://www.wikidata.org/wiki/Q109336893

https://www.wikidata.org/wiki/Q111383587

Thanks, --Ooligan (talk) 03:48, 11 April 2022 (UTC)

Wikidata weekly summary #515

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • Glitter another R package to write SPARQL queries and query Wikidata and other SPARQL endpoints. This package provides a domain specific language to write queries directly from R.
    • Conzept is a topic-exploration tool based on Wikidata and other information sources.
  • Development
    • Lexicographical data: Continued work on the new Special:NewLexeme page. We worked on displaying error messages and inferring the spelling variant from the language. We also looked into the non-JavaScript version of the page.
    • REST API: Worked on conditional requests (do not return data the client already has) and authorization.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.


Name changing - Q111580796

Hi, I'd like to change this item's name to "Ruth Navon (geneticist)". Also, I'll ask you to delete the redundant item "Ruth Navon (genetists)". Both were created by mistake. Thanks in advance, קוונטום דוץ (talk) 15:21, 11 April 2022 (UTC)

@קוונטום דוץ I merged the two items. There is no need for an alias with the profession in brackets. --Emu (talk) 16:18, 11 April 2022 (UTC)

Q111570369

Please delete the element, it is a copy of another element. I accidentally made a mistake when creating. Загребин Илья (talk) 14:24, 11 April 2022 (UTC)

If it is a duplicate, it should be merged, not deleted. --Ameisenigel (talk) 14:50, 11 April 2022 (UTC)
Let's do. I don't know, how. Загребин Илья (talk) 17:21, 11 April 2022 (UTC)
@Загребин Илья: could you please link where the already existing item is? Thanks, Bencemac (talk) 16:54, 12 April 2022 (UTC)
Bencemac, link is in the title of the section. Загребин Илья (talk) 17:10, 12 April 2022 (UTC)
I see, but where is the other one (the another element)? Bencemac (talk) 17:13, 12 April 2022 (UTC)
Ooups. No. This is the right link: Q111317950. Загребин Илья (talk) 17:13, 12 April 2022 (UTC)
I merged the two items. Bencemac (talk\) 17:17, 12 April 2022 (UTC)
Thanks. Загребин Илья (talk) 17:24, 12 April 2022 (UTC)

I'd like to creat new elements

Where I can see elements to creat? Zagrebin Ilya (Talk page) 06:57, 13 April 2022 (UTC)

Programmatically get Image properties as json

The painting

Wikimedia provides some information about the images of artworks.

Example: https://commons.wikimedia.org/wiki/File:Gustave_Courbet_-_The_Brook_of_Les_Puits-Noir_-_1933.1117_-_Art_Institute_of_Chicago.jpg

It displays the information "artist", "Object Type", "medium", "Collection", etc.

It seems to me that the given information is got [wikidata] because the wikicode is essentially a link:

== {{int:filedesc}} == {{Artwork |source=https://www.artic.edu/artworks/16490 |wikidata=Q20267840 }}

I want to programmatically get these information as (preferably) json.

The best I found is [json] but it does not contain most of the fields I'm searching for.

Laurent.Claessens (talk) 11:30, 13 April 2022 (UTC)

@Laurent.Claessens: the artwork data is on Wikidata at The Brook of Les Puits-Noir (Q20267840) and you can get that as structured data, for example json or jsonld. More formats available at Special:EntityData. Multichill (talk) 14:41, 13 April 2022 (UTC)
Thanks for your answer, @Multichill:. My point is that the wikidata json contains "oil" and "canvas" in two separate values for the properties P186 and under the form of references to Q296955 (oil painting) and Q12321255 (canvas). Seems pretty difficult to parse and get the string "oil on canvas". Clearly Wikimedia already made the work of creating expressions like "oil on canvas" from the wikidata json.
I'd like to get the already formed string "oil on canvas". Laurent.Claessens (talk) 18:54, 13 April 2022 (UTC)
This nice string is generated in the Commons template, and is not available directly from Wikidata. If you look at commons:Template:Artwork, you'll see that the default value for the "medium" field is [[d:Special:EntityPage/P186|made from material <small>(P186)</small>]], [[d:Special:EntityPage/P2079|fabrication method <small>(P2079)</small>]]. You could reproduce this with a carefully-crafted SPARQL query. Bovlb (talk) 20:57, 13 April 2022 (UTC)
@Laurent.Claessens: the list of combinations isn't that big, see Wikidata:WikiProject sum of all paintings/Top material combinations
Parsing is done at c:Module:Wikidata_art#L-288. Multichill (talk) 21:41, 13 April 2022 (UTC)
Thanks a lot @Multichill: and @bobvld:. That answers my question.

Movement Strategy and Governance News – Issue 6

Movement Strategy and Governance News
Issue 6, April 2022Read the full newsletter

Welcome to the sixth issue of Movement Strategy and Governance News! This revamped newsletter distributes relevant news and events about the Movement Charter, Universal Code of Conduct, Movement Strategy Implementation grants, Board of trustees elections and other relevant MSG topics.

This Newsletter will be distributed quarterly, while the more frequent Updates will also be delivered weekly. Please remember to subscribe here if you would like to receive future issues of this newsletter.

  • Leadership Development - A Working Group is Forming! - The application to join the Leadership Development Working Group closed on April 10th, 2022, and up to 12 community members will be selected to participate in the working group. (continue reading)
  • Universal Code of Conduct Ratification Results are out! - The global decision process on the enforcement of the UCoC via SecurePoll was held from 7 to 21 March. Over 2,300 eligible voters from at least 128 different home projects submitted their opinions and comments. (continue reading)
  • Movement Discussions on Hubs - The Global Conversation event on Regional and Thematic Hubs was held on Saturday, March 12, and was attended by 84 diverse Wikimedians from across the movement. (continue reading)
  • Movement Strategy Grants Remain Open! - Since the start of the year, six proposals with a total value of about $80,000 USD have been approved. Do you have a movement strategy project idea? Reach out to us! (continue reading)
  • The Movement Charter Drafting Committee is All Set! - The Committee of fifteen members which was elected in October 2021, has agreed on the essential values and methods for its work, and has started to create the outline of the Movement Charter draft. (continue reading)
  • Introducing Movement Strategy Weekly - Contribute and Subscribe! - The MSG team have just launched the updates portal, which is connected to the various Movement Strategy pages on Meta-wiki. Subscriber to get up-to-date news about the various ongoing projects. (continue reading)
  • Diff Blogs - Check out the most recent publications about Movement Strategy on Wikimedia Diff. (continue reading)

--YKo (WMF) (talk) 06:56, 14 April 2022 (UTC)

@YKo (WMF): This sort of highly formatted, attention grabbing spam, is IMO most unwelcome on central talk pages. In my ~18 year observation of wikimedia talk pages, there is absolutely no tradition of appending adverts with, for instance, their own header in a font size much greater than the normal heading font. It is a small point, but it does seem to me to reflect how little WMF seems to understand or care for the way things are done on wiki. I do beg you, too, to spare us the weekly updates. --Tagishsimon (talk) 13:05, 14 April 2022 (UTC)

A hyperlink for a specific statement?

I wonder if Wikibase supports adding a link to any statement on an item page. If I have a statement I wish to share with someone over the internet, how do I do that?

I guess it's not supported yet. How do I submit a feature request or check if it's already a part of the backlog? Nikolay Komarov (talk) 09:24, 14 April 2022 (UTC)

@Nikolay Komarov: Q5778278#P461? Q5778278#Q5778278$87704643-425e-ff23-0ac1-2df266a41ac4? Just look in the source for id=.... Multichill (talk) 10:37, 14 April 2022 (UTC)

Closure request

This discussion seems to have run its course, with what looks to me like a consensus, and no new comments in two weeks. Since it's a matter that may come up again in the future, I think there would be value in having an uninvolved editor close and summarize the discussion with {{Discussion top}}/{{Discussion bottom}}. Thanks! Swpb (talk) 17:59, 14 April 2022 (UTC)

Wikidata metrics on the Dashboard

Hi everyone,

Just a quick announcement to share that Wikidata metrics are now easily accessible on the Dashboard. We have a little blog post detailing the process that you can read here. Here's an example Dashboard you can check out to see the new features in action. If you have any questions or feedback, feel free to reach out. It's our hope that these new metrics can help track the impact of projects, assist with storytelling, and provide more detail about specific project work. Thanks! Will (Wiki Ed) (talk) 18:21, 14 April 2022 (UTC)

Nouveau chapitre de thèse

Bonjour, voici un nouveau chapitre de ma thèse que je vous invite à commenter si cela vous tente. Je décris tout le système politique du mouvement cette fois-ci. Une belle journée à tous ! Lionel Scheepmans ✉ Contact Désolé pour ma dysorthographie, dyslexie et "dys"traction. 20:03, 14 April 2022 (UTC)

Join the Wikimedia Foundation Annual Plan conversations with Maryana Iskander

You can find this message translated into additional languages on Meta-wiki.
More languages • Please help translate to your language

Hello,

The Movement Communications and Movement Strategy and Governance teams invite you to discuss the 2022-23 Wikimedia Foundation Annual Plan, a plan of record for the Wikimedia Foundation's work.

These conversations continue Maryana Iskander's Wikimedia Foundation Chief Executive Officer listening tour.

The conversations are about these questions:

  • The 2030 Wikimedia Movement Strategy sets a direction toward "knowledge as a service" and "knowledge equity". The Wikimedia Foundation wants to plan according to these two goals. How do you think the Wikimedia Foundation should apply them to our work?
  • The Wikimedia Foundation continues to explore better ways of working at a regional level. We have increased our regional focus in areas like grants, new features, and community conversations. What is working well? How can we improve?
  • Anyone can contribute to the Movement Strategy process. Let's collect your activities, ideas, requests, and lessons learned. How can the Wikimedia Foundation better support the volunteers and affiliates working in Movement Strategy activities?

You can find the schedule of calls on Meta-wiki.

The information will be available in multiple languages. Each call will be open to anyone to attend. Live interpretation will be available in some calls.

Best regards,
--YKo (WMF) (talk) 05:41, 15 April 2022 (UTC)

antichrist

i would like to add on a special article about the antichrist its 2022 and we need one badly User talk:80.233.35.141

Already exists: Antichrist (Q174546), and this is NOT wikipedia. Taylor 49 (talk) 13:31, 15 April 2022 (UTC)

disallowed-entity-types constraint

I'd like to make a constraint to catch scholarly articles inadvertently used in place of their subjects, since they often have the same label. For example, Duke L. Kwon (Q111607851)field of work (P101)Racial Reconciliation (Q56212095), where Racial Reconciliation (Q56212095)instance of (P31)scholarly article (Q13442814).

Ideas:

  1. field of work (P101)property constraint (P2302)disallowed-entity-types constraintitem of property constraint (P2305)scholarly article (Q13442814)
  2. field of work (P101)property constraint (P2302)none-of constraint (Q52558054)class (P2308)scholarly article (Q13442814)

How do I do this? Daask (talk) 16:38, 15 April 2022 (UTC)

Wikisource Sitelinks Policy

Over the past several months, some Wikidata editors have been deleting Wikisource sitelinks from literary work data items and moving them to newly created version/edition/translation items linking to the original work. These changes break the sitelinks system for Wikisource because Property:P747 is not searched for additional language links, for very good reasons. The problem currently affects over 6500 Wikisource pages, making them inaccessible from other Wikisource language versions through the sitelinks system. In addition, those changes also violate at least three different editing guidelines which implicitly state that Wikisource sitelinks belong primarily on the data item of the main literary work:

I'd like to propose the following solution:

  • Clarify Wikisource: How to Help to explicitly state that the main data item of a literary work must link to an appropriate page on all Wikisource language domains where the literary work is available. Which page is "appropriate" will be decided by the respective Wikisource language community.
  • Add a constraint check to Property:P747 that will indicate an issue when the child data item has a link to Wikisource language domain which is missing on the parent data item.
  • Fix those 6500+ Wikisource pages by moving the sitelinks to the main literary work data items.

Next ghost (talk) 19:23, 14 April 2022 (UTC)

No. The thing on Wikisource is a version/edition. It's quite right for a WD item on the same version/edition to point to the WS version/edition. It's unclear what the problem you're observing on WS is, but you've not made a compelling argument for WD changing what it does. Not least, I'm unclear how your suggestion works if WS has two distinct editions of the same literary work. --Tagishsimon (talk) 19:34, 14 April 2022 (UTC)
My suggestion does not apply to WS domains with multiple editions of the same work because the main data item already links to a disambiguation page and the existing version/edition data items are linked correctly. Only works with single version of the text on Wikisource are affected by the problem. Here's an example: The Ugly Duckling has a total of 11 language versions on Wikisource but only 3 of them are visible through the sitelinks system as you can see e.g. on the Romanian Wikisource which does not use any explicit interwiki links in the page text. The Romanian text itself is not visible from any other language version of Wikisource because it's linked to an edition data item instead of the main work as it should be according to written guidelines. If you want to change the guidelines to "legalize" the recent breaking changes, you'll have to ask for approval from all Wikisource communities because you'll be changing guidelines for a system created primarily for their use. Next ghost (talk) 20:25, 14 April 2022 (UTC)
Yes. It's kinda sort of like the Bonnie & Clyde problem. Still, WD is doing the correct thing in linking WD edition items to WS edition pages. Arguably any sitelink from a WD literary work to a WS edition of that work is wrong; WD should have an edition item. I respect that that all means that sitelinks, on their own, cannot be relied on in WS to link one edition to the next, one language version to the next. But you fix that problem not by screwing up and bodging the wikidata, but by developing technology - a template perhaps - which can cope with the not very big leap from a WD edition item to its WD literary work item. Something like Common's Wikidata Infobox would do the trick. You speak of "written guidelines", but WD is not bound by anything written on WS, and I'm unaware of any guidelines agreed by the WD community which say "link apples to pears to help a poor WMF site out". WD does not have to ask WS for approval. You have, in short, an admitted problem, but also ahold of the wrong end of the stick. --Tagishsimon (talk) 20:47, 14 April 2022 (UTC)
Sitelinks documentation and Wikisource: How to Help are both Wikidata guidelines for working with sitelinks. Next ghost (talk) 21:55, 14 April 2022 (UTC)
Hmm, I think the issue here is what exactly documents on Wikisource mean. Are they like the encyclopedic articles on a Wikipedia, that are "about" a particular work (in all its editions and translations)? Or are they themselves works that are editions/translations of the work in question. If the latter then the interwiki-linking solution that works for Wikipedias simply is not correct for Wikisource, and WMF/Mediawiki devs need to fix it. ArthurPSmith (talk) 21:00, 14 April 2022 (UTC)
Asking what they're about is a little like asking about intentionality w.r.t. a crime. The fact remains that a wikisource document which is a copy of an edition or version, is an edition or version. And should be linked to a WD edition/version item. WMF/Mediawiki devs - despite WMF having 600ish staff - has shown no interest in solving Bonnie & Clyde, so I'd not hold out for them solving WS's problem. --Tagishsimon (talk) 21:22, 14 April 2022 (UTC)
I would argue that the sitelinks records should stand outside the regular Wikidata ontology and Sitelinks documentation strongly suggests that that was the intent behind the feature all along. Sitelinks to various wikiprojects are not inherent properties of the entities described by data items. Sitelinks are an interface for the wikiprojects to access additional features provided by Wikidata. Therefore sitelinks should follow the best approximation approach to fulfill the needs of those wikiprojects rather than trying to shoehorn wikipages into some rigid information structure. After all, the discussion about the Bonnie & Clyde problem is a discussion how to best serve the needs of wiki users reading about Bonnie and Clyde. Next ghost (talk) 22:12, 14 April 2022 (UTC)
Well, good luck with that argument. WS's time would be better spent developing a template which provides interwiki links based on WD's standard for Bibliographic Records, which makes a clear distinction between a work and its manifestations. Your "argue that the sitelinks records should stand outside the regular Wikidata ontology" is just a posh way of asking WD not to link an WD edition item to an edition WS page, but rather link the WD work item because neither WMF nor WS feel like putting in place templates or code to solve the not-hugely-difficult parent/child problem. Break the data because we lack a means of implementing a software solution. As I said at the start: no. --Tagishsimon (talk) 22:30, 14 April 2022 (UTC)
OK, let's see what solving the "not-hugely-difficult" parent/child problem would look like in practice. There are currently 75 Wikisource language domains and there may be hundreds in the future. So the list of links can also have hundreds of items. Whether it'll be a wiki sidebar or an infobox template inserted into page text doesn't matter, the contents will be exactly the same. Next, you don't want to label the links with the name of the literary work or edition, otherwise you'll end up with dozens of links saying e.g. "Iliad" pointing to different languages. You want to label the links with language names because that's what the user will be looking for. You also don't want a dozen links saying "English" pointing to different version of the text because the user has no way to tell the links apart. You want one link per language pointing to a disambiguation page or the edition text itself. And if the Wikisource community did not link any disambiguation page to the data item of the main literary work, you'll have to generate one automatically on demand. Sounds easy so far, right? Well, not so fast. What are you going to show on the autogenerated disambiguation page? All you have to work with is what's in the text edition data item. And there can be literally nothing else but the Wikisource sitelink and a reference to the parent data item. No translator, no publisher, no publication date, nothing. So again, you'll end up with a handful of links all saying e.g. "Iliad" and no way to tell them apart. I bet the WMF developers went through this design process and realized that any technical solution they create will be garbage. This is a problem that needs a bureaucratic solution instead and any technical solution they would create will only distract wiki communities from solving the problem properly. All the tools for implementing the bureaucratic solution already exist - sitelinks, disambiguation pages and redirects. The only thing left is for wiki editors to agree how to use them. Next ghost (talk) 13:28, 15 April 2022 (UTC)
@Next ghost: I'm a bit confused. Wikisources have both pages for works and editions. s:en:The Odyssey is a work (or close enough to be assimilated) and s:en:Odyssey (Pope) is an edition (same caveat). There is a consensus on that for along time and it seems it is what is reflected both in the policies you mention and in the uses of the community. Am I missing something?
« because Property:P747 is not searched for additional language links », uhh? we have the mw:Extension:Wikisource for that (since 2017). Again, am I missing something?
Cheers, VIGNERON (talk) 06:48, 16 April 2022 (UTC)
There are currently 6500+ edition pages with no corresponding Wikisource page for the main work. Most of those "orphan" edition items have been created in recent months and their Wikisource link was moved from the main work data item, which broke interwiki navigation. I am simply asking for policy clarification that when someone moves a Wikisource link from the main work data item to a new edition item, they have to backfill the main work item with something appropriate. In this situation, removing the Wikisource link from the main work data item without replacement is a data integrity error. The Wikisource extension only searches Property:P629 when generating interwiki links. You can see this for yourself in EditionLookup.php: The getEditions() method is not called anywhere in the code. Next ghost (talk) 18:44, 16 April 2022 (UTC)
@VIGNERON:Separate page for work and edition have only few projects, majority have only page for edition and the page for work only in case when more editions have own page. eg. on cs.wikisource we have at least 750 works with subpages (editions) and hundrets of work without subpage (editions, news articles etc), but only 38 "thematic disambiguations" (some of them are about work).
On edition with this extension page you can usually see only link which are on "work" item, but not editions on this item. Look at ro:Corbul_(Poe,_Caragiale) - there are only links from work. And then look to sv:Korpen_(Poe) - this wiki uses special module and you are able to see all other editions - and that'a the point Next ghost is talking about.
Is possible to use the script from sv+pl wikisource and enable edition links on all wikisources. JAn Dudík (talk) 17:04, 17 April 2022 (UTC)
@Next ghost, JAn Dudík: oh, I see now, thanks. Indeed when correcting a mistake it's not a good idea to stop midway, but I would say it's still better to half-correct than just leaving the error in the first place. Cheers, VIGNERON (talk) 18:00, 17 April 2022 (UTC)
this script and this module:Q86127036 can display editions via Wikidata on every wikisource. JAn Dudík (talk) 18:50, 17 April 2022 (UTC)

Wikidata weekly summary #516

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: Pi admin bot (RfP scheduled to end after 20 April 2022 17:58 UTC)
    • Closed request for adminship: Stang (successful)
    • New requests for permissions/Bot:
  • Tool of the week
    • Bird O'Clock! is a tool based on Wikidata and other data sources that shows pictures and numbers from actual people counting actual birds in the actual world!
    • Tiago's Coin Herbarium is a coin collection depicting different plant information displayed via Wikidata SPARQL queries.
  • Development
    • Lexicographical data: Worked on inferring the spelling variant from the language's Item on the new Special:NewLexeme page and started building a little help box on the special page to explain what lex. data is.
    • REST API: Getting closer to having a first version of the REST API that returns Item data.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.


Merge plant synonyms?

I wanted to merge Michelia figo (Q15613376) to Magnolia figo (Q311864), but I noticed that another synonym for the same plant, Liriodendron figo (Q15613379), has its own item. What's the procedure here to get all of the Wikipedia links listed together? AjaxSmack (talk) 15:03, 18 April 2022 (UTC)

@AjaxSmack You can move the sitelinks to any item you like. But please keep all taxon items separate (do not merge!) - each scientific name has its own item in Wikidata. Vojtěch Dostál (talk) 12:29, 19 April 2022 (UTC)
​Thanks. AjaxSmack (talk) 21:18, 19 April 2022 (UTC)

Name for Swinton Community School (Q16900993)

Not sure how renames are done in wikidata, probably best that I do not know. Hoping that it is fair (vs avoid being a burden on other editors) to request that Swinton Community School (Q16900993) be renamed as Swinton Academy. It converted to an academy, per the 2010 Academies Act, in 2016. Thanks. Jmg38 (talk) 23:34, 18 April 2022 (UTC)

Done. Your request was completely fair and not a burden at all. :) --Quesotiotyo (talk) 18:35, 19 April 2022 (UTC)

WikiProject Clinical Trials for Wikidata - the paper

WD:CT

See Wikidata:WikiProject Clinical Trials. Care about this because

  1. We presented it as a model WikiProject in this new preprint - https://doi.org/10.1101/2022.04.01.22273328
  2. It is a tidy cool WikiProject which coordinated the import of ClinicalTrials.gov (Q5133746) to Wikidata
  3. I and others will continue to develop this project and further integrate it with Wikidata for medicine, universities, biographical records of medical researchers, and meta:WikiCite

Comments requested here or at the WikiProject talk page.

THANKS TO ANYONE WHO COMMENTS! Bluerasberry (talk) 19:22, 19 April 2022 (UTC)

Germans have invaded city hall

We used to have city hall, but now it became rathaus? What the heck? @BohemianRhapsody, VIGNERON, Fralambert: I understand you trying to clean up based on these edits, but the last time City Hall (Q2587792) was a rathaus, was in WWII. You seem to have the mess even bigger than it was in your attempts to fix it. Maybe better to revert and start over? Changing the meaning of a widely used item is not the way to go. Probably better to split out in specific well defined items like we did with mayor of a place in the Netherlands (Q13423499)? Multichill (talk) 12:29, 14 April 2022 (UTC)

I don't remember all the details and I'm not sure if the mess was bigger before or after (the second version of this item was already very confusing and confused). But clearly it's a mess now.
Not sure what is the solution, revert doesn't seem right, maybe the best now would be to entirely delete this item and start other? And agreed, mayor of a place in the Netherlands (Q13423499) is what we should aim for.
Cheers, VIGNERON (talk) 15:04, 14 April 2022 (UTC)
Revert does indeed seem right. Difficult to delete an item on which hundreds of other items have a dependency. --Tagishsimon (talk) 17:10, 14 April 2022 (UTC)
Revert or not, in both cases, there is at least ~5000 items to clean anyway. Cheers, VIGNERON (talk) 18:52, 14 April 2022 (UTC)
town hall (Q25550691) is the broader term for every city hall, while "Rathaus" is a specific word used only in German language, so it's correct that Rathaus is a subclass of town hall. Before of my edits, rathaus (Q543654) already had most of his Wikipedia links pointing to "Rathaus" pages, I just fixed the labels to reflect this. The problem is in the use of rathaus (Q543654) in Wikidata items that aren't in German-speaking countries. Maybe these items can be fixed by a bot? --BohemianRhapsody (talk) 08:31, 15 April 2022 (UTC)
842 German items with this P31. 4,862 non-German items with this P31. There's no 'just' about this. You're breaking wikidata on an industrial scale. In general, the onus is on users not to do this sort of thing: not to make a huge mess and stand back expecting other people to clear it up. If you take on the responsibility for changing the semantics of an item to fit your idea of what the item truly represents, you need to take on responsibility for fixing the 85.2% of items you've broken. --Tagishsimon (talk) 09:58, 15 April 2022 (UTC)
It looks like the "town hall" sitelinks are split between the two items. de:Gemeindehaus (Kommune) at Q25550691 is limited to German-speaking countries and seems to describe different things; it's probably closer to "parish hall" or "village hall" in Germany and Austria, and is only the same as "town hall" in Switzerland. de:Rathaus is not specific to any country, and de:City Hall (London) is described as a Rathaus. Q3604202 (talk) 07:18, 20 April 2022 (UTC)

Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines

More languages • Please help translate to your language

The Community Affairs Committee of the Wikimedia Foundation Board of Trustees would like to thank everyone who participated in the recently concluded community vote on the Enforcement Guidelines for the Universal Code of Conduct (UCoC).

The volunteer scrutinizing group has completed the review of the accuracy of the vote and has reported the total number of votes received as 2,283. Out of the 2,283 votes received, a total of 1,338 (58.6%) community members voted for the enforcement guidelines, and a total of 945 (41.4%) community members voted against it. In addition, 658 participants left comments with 77% of the comments written in English.

We recognize and appreciate the passion and commitment that community members have demonstrated in creating a safe and welcoming culture that stops hostile and toxic behavior, supports people targeted by such behavior, and encourages good faith people to be productive on the Wikimedia projects.

Even at this incomplete stage, this is evident in the comments received. While the Enforcement Guidelines did reach a threshold of support necessary for the Board to review, we encouraged voters, regardless of which way they were voting, to provide feedback on the elements of the enforcement guidelines that they felt needed to be changed or fixed, as well as why, in case it seemed advisable to launch a further round of edits that would address community concerns.

Foundation staff who have been reviewing comments have advised us of some of the emerging themes, and as a result we have decided as Community Affairs Committee to ask the Foundation to reconvene the drafting committee and to undertake another community engagement to refine the enforcement guidelines based on the community feedback received from the recently concluded vote.

For clarity, this feedback has been clustered into 4 sections as follows:

  1. To identify the type, purpose, and applicability of the training;
  2. To simplify the language for easier translation and comprehension by non-experts;
  3. To explore the concept of affirmation, including its pros and cons;
  4. To review the conflicting roles of privacy/victim protection and right to be heard.

Other issues may emerge during conversations, and particularly as the draft Enforcement Guidelines evolve, but we see these as the primary areas of concern for voters and are asking staff to facilitate review of these issues. After further engagement, the Foundation should re-run the community vote to evaluate the revamped Enforcement Outline to see if the new document is then ready for its official ratification.

Further, we are aware of the concerns with the note 3.1 in the Universal Code of Conduct Policy. We are directing the Foundation to facilitate a review of this language to ensure that the Policy meets its intended purposes of supporting a safe and inclusive community, without waiting for the planned review of the entire Policy at the end of year.

Again, we thank all who participated, thinking about these critical and difficult challenges and contributing to better approaches across the movement to working together well.

Best,

Rosie

Rosie Stephenson-Goodknight (she/her)
Acting Chair, Community Affairs Committee
Wikimedia Foundation Board of Trustees
YKo (WMF) (talk) 04:06, 20 April 2022 (UTC)

Help needed for merging

Hello, I want to merge

  • Q97170323 Cupra Born, created on July 12th, 2020‎

with the older

  • Q61934112 [SEAT el-Born/ Cupra el Born], March 1st, 2019‎

However at the page Special:MergeItems I get the message that „‪Q97170323“ is unknown. What is my mistake? --KaPe (talk) 17:05, 17 April 2022 (UTC)

Both items have sitelinks for the same project, so it is not possible to merge them. By the way, it does not look to me like Cupra Born (Q97170323) and SEAT el-Born (Q61934112) are the same thing. --Ameisenigel (talk) 18:24, 17 April 2022 (UTC)
Hello Ameisenigel, in your answer we have the technical aspect („items have sitelinks for the same project“) where my English isn‘t sufficient to unterstand the meaning (auf Deutsch?). And the content question – should we regard the two wikidata items as referring to the same object. Lacking the knowledge of the place to discuss the merging, I had tried to act according to de:WP:Sei mutig, or en:WP:Be bold. Where is that discussion place? --KaPe (talk) 12:10, 19 April 2022 (UTC)
One item links to cs:CUPRA Born and the other links to cs:SEAT el-Born. If they are the same then these articles will need to be merged — Martin (MSGJ · talk) 16:05, 20 April 2022 (UTC)

Global Species List Working Group

I have made a post on Wikispecies to request information from Wikispecies, Wikidata, and Wikipedia editors who work with species taxonomy. I am aware of WMF policies, but this is a crucial gathering of information and I believe its important that editors here on WMF have their say as you are producing checklists. Thanks everyone, cheers Scott Thomson (Faendalimas) talk 18:23, 20 April 2022 (UTC)

"has use" qualifier for P31 values

My colleagues and I are working on the upload of the Scène Pro (Q111597636) dataset that includes entities of a class named "salle de spectacle" in the local database. This class describes performing spaces within performing arts buildings. This class does not exist in Wikidata. The closest concept is event venue (Q18674739), but it's a much, much broader class. The simplest solution might be to create a new class item for this concept. However, members of the WikiProject: Cultural venues are hesitant, because the concept does not seem to exist in thesauri and authority files (with the exception of this [terminology database record]).

In the absence of a clear consensus on the creation of a new class item, we are planning to describe these entities as instance of (P31)event venue (Q18674739). We are further considering to add a qualifier to distinguish these entities from sports stadiums, convention centres and ski resorts and other entities in the same subclass hierarchy. My first thought was to qualify them as event venue (Q18674739)of (P642)performing arts (Q184485). However, of (P642) is slated for deprecation and the property description recommends the use of a more specific property. The most specific property to qualify rooms/halls in the Scène Pro (Q111597636) dataset is has use (P366). The problem is, has use (P366) is not an allowed qualifier for instance of (P31).

I do not want to edit instance of (P31) constraints without consulting the Wikidata community. Should we add has use (P366) as an allowed qualifier for instance of (P31)? Should we opt for of (P642) and keep fingers crossed that it isn't deprecated too soon? Or are there other solutions that my colleagues and I should consider?

Beat Estermann (talk) 22:21, 31 March 2017 (UTC) Beireke1 (talk) Beireke1 (talk) 12:07, 2 May 2017 (UTC) - collaborating with Romaine on Belgian data on performing arts venues. Affom (talk) 15:26, 12 May 2017 (UTC) Anvilaquarius (talk) 11:41, 15 September 2017 (UTC) PEAk99(talk) PEAK99 (talk) 20:32, 29 January 2019 (UTC) Boxomi (talk) 22:21, 24 September 2019 (UTC) Antoine2711 (talk) 00:19, 5 December 2019 (UTC) Fjjulien (talk) 21:15, 13 February 2020 (UTC) Vero Marino (talk) 21:15, 13 February 2020 (UTC) Bello Na'im (talk) 08:34, 24 September 2021 (UTC) Titanboo (talk) 17:23, 8 July 2022 (UTC) dlh28 (talk)18:21, 22 September 2022 (UTC)

Notified participants of WikiProject Cultural venues

Beat Estermann
Affom
Vladimir Alexiev
Birk Weiberg
Smallison
Daniel Mietchen
Buccalon
Jneubert
Klaus Illmayer
Katikei
GiFontenelle
Antoine2711
Fjjulien
Youyouca
Vero Marino
Celloheidi
Beireke1
Anju A Singh
msoderi
Simon Villeneuve
VisbyStar
Gregory Saumier-Finch
Rhudson
DrThneed
Pakoire
Gabriel De Santis-Caron
Raffaela Siniscalchi
Aishik Rehman
YaniePorlier
SAPA bdc
Joalpe
bridgetannmac
Nehaoua dlh28
LiseHatt
Zblace
Bianca de Waal
MichifDorian

Notified participants of WikiProject Performing arts Fjjulien (talk) 02:48, 14 April 2022 (UTC)

@Fjjulien Why not use has use (P366) as independant statement ? I would propose not use of (P642) as qualifier. There was already many discussion about the bad efficacity of it. SAPA bdc (talk) 08:18, 14 April 2022 (UTC)
Using P366 as a main statement is indeed an option. Personally, I would prefer it if has use (P366) statements were added to class items - and could therefore be inferred to all instance of these classes. Otherwise, we have completeness issues that makes the data less reusable. However, in the case at hand, we are missing the class item, hence my suggestion of using a qualifier. This being said, unless the community provides any feedback on allowing P366 as an allowed P31 qualifier, then we'll have no other choice but to use it as a main statement. Fjjulien (talk) 17:28, 19 April 2022 (UTC)
  • @Fjjulien: subject has role (P2868) is probably the more commonly used property as a qualifier; though typically with the sense that "the main statement is true when the item has this role", in a case when an item is covering a thing which can have more than one role.
Personally I would create a new class for "salle de spectacle" -- it seems a well-enough defined concept, narrower and more precise than "event venue", so it would be a good thing to have an item for it. Jheald (talk) 18:17, 19 April 2022 (UTC)
Participants in the WikiProject Cultural venues once discussed the idea of creating a new class item and hesitated to (see this discussion). In the light of the data structure in this dataset, we will have to revisit this idea in an upcoming meetup. Fjjulien (talk) 22:01, 20 April 2022 (UTC)
@Jheald: @SAPA bdc: After discussion with my colleagues, we retained two options:
  1. P31 qualifier event venue (Q18674739)of (P642)performing arts (Q184485): The qualifier tells human users that the value is not granular enough to accurately describe the subject. If a new class item is eventually created, we will update these items and use the new value instead.
  2. Main statement has use (P366)performing arts (Q184485): This main statement will facilitate queries and data reuse.
Here is a sample item from the upload: Salle Cogeco (Q111669162). Fjjulien (talk) 22:12, 20 April 2022 (UTC)
Jheald gave good advice; I'm sorry you've decided instead to use the most unhelpful qualifier available - User:Lucas Werkmeister/P642 considered harmful. --Tagishsimon (talk) 00:55, 21 April 2022 (UTC)

Roller Coasters with unrealistically high speeds

I just noticed an issue with several roller coaster (Q204832), that have rediculously high speed (P2052) (<insert Space Balls Ludicrous Speed Meme here>) assigned to them, of more than 500 km/h. I am not sure if this is vandalism or unit conversion errors (probably a bit of both), but I currently don't have the time to look into this and fix them, so maybe somebody else has a few minutes to spare.

Here is the query that returns the 10 items in question: https://w.wiki/55Lt .

The currently fastest roller coaster in the world is Formula Rossa (Q25002) with a top speed of 240 km/h (149.1 mph), and Euthanasia Coaster (Q610172) is also correctly modelled with its 360 km/h, as this is a theoretical/satirical concept only.

Thanks, Frog23 (talk) 16:15, 20 April 2022 (UTC)

Your query gives only the numeric values and ignores the given units for the speed, so the values cannot be compared as they can have different units. I suggest using normalized values in m/s by changing ?rc wdt:P2052 ?speed to ?rc p:P2052 / psn:P2052 / wikibase:quantityAmount ?speed in the query. If you prefer you can then multiply with a constant to get e.g. km/h or mph instead. But still, you are right that the speeds are too high. --Dipsacus fullonum (talk) 16:38, 20 April 2022 (UTC)
One item had been vandalised; the others were errors caused by using a comma as a decimal point. Q3604202 (talk) 13:37, 22 April 2022 (UTC)

P16 How to retrieve data from Wikidata

Hi 😊 Friends I am Monica Please 🥺🙏 Tell me how i can retrieve data from Wikidata. Because I am New and I really need to know some Stuffs From here and I need to know Your names Thanks Please don't delete my Chat Thanks ❤️❤️❤️❤️❤️😍— Preceding unsigned comment added by 105.112.151.75 (talk) 09:21, 22 Apryle 2022‎ (UTC)

How to proceed

Dear Wikidata members,

Since I am new to Wikidata I thought the best way to act now is to ask a question. At the moment I am keen to understand how to proceed for a specific data import. The Wikidata:Dataset Imports page has a warning that it is inactive and the module also doesn't provide the specifics I am looking for (I don't have a distinct online dataset, I have my own, see below.) Also I see that on Wikidata:Bot requests there is rather a large list with requests and (I haven't read them all, but) sometimes it is mentioned that a discussion is required first. I hope this is the right place to start that discussion, and if not, I hope to learn where to address my questions / requests.

Based on data from Statistics Netherlands (Q167086) I have created a dataset with the population per municipality per month. The current version of the script runs for februari 2022. In this set I have joined data from two Statistics Netherlands sources and added Wikidata item-ID's and some Properties that might be of importance.

At this moment the script produces a dataframe / spreadsheet and isn't the most pretty code. The python script and a result table can be found here. Please have a look and share your thoughts with me, any kind of feedback is welcome. The idea is that it can run every month forward (and back to 2002 with a few changes - because the data needs to map on old municipalities) and needs revision once the municipalities change (which is annual and sometimes more frequent). The published script is 'just' a script that generates a desired dataset. First I wrote building blocks in two layers (reusable functions and data specific functions) which still is visible in the script. For communication purposes on the Dutch wiki and here I moved it into one script. And I was too lazy to set up a main().

Please advice me how to proceed... Démarche Modi (talk)

Monthly data is too granular for Wikidata; items become unusable when they have hundreds or thousands of statements, and each month would be its own statement for something like this. Wikimedia Commons has a tabular data format you could use, and we have tabular population (P4179) to link to those files from here. It would probably be helpful to place the most up-to-date value on the item here though too. ArthurPSmith (talk) 19:56, 20 April 2022 (UTC)
Thank you, I'll look into this. With your last sentence, do you mean to have one P1082 which is periodically overwritten with the latest value? Démarche Modi (talk) 07:35, 21 April 2022 (UTC)
@Démarche Modi: Yes, that is what I had in mind there. ArthurPSmith (talk) 19:26, 22 April 2022 (UTC)
Also as a note, the latest value should be marked as preferred. AntisocialRyan (Talk) 22:16, 22 April 2022 (UTC)

Global unicode attack

"User:Ekirahardian cont User:Ekirahardian" is about to upload SVG images of all Unicode characters to commons. This is of course good if done in a legal way. A related strange effect is uploading of thousands of huge modules to hundreds of wiktionaries (example) by "User:Ekirahardian" and "User:Kwamikagami", identical with each other, and needing frequent updates. On some wikis those modules got deleted equally quickly as they were created. Uploading affects particularly "weak" wikis (eowikt, idwikt), while no such modules have been uploaded to svwikt (having a well working bunch of active sysops) so far. All that those modules do is to convert a unicode codepoint thus an integer into 2 strings: offcial name of the char, and filename on commons. IMHO this should be done via wikidata, and those local modules should be deleted. I advocate to stop uploading and updating those modules until an efficient global solution has been elaborated. Taylor 49 (talk) 13:28, 15 April 2022 (UTC)

Speaking of efficiency, direct mapping via Lua is orders of magnitude faster than using Wikibase, Semantic Mediawiki and such. I doubt efficiency matter in this case though, it just seems like lack of planning. As for solutions, how about just adding image (P18) to instances of Unicode character (Q29654788), will that do? Or maybe sitelink to commons is better? Infrastruktur (talk) 13:49, 15 April 2022 (UTC)
I actually support this if that means we can have a centralized way to maintain the name and the images of the Unicode characters. AFAIK, modules that convert a Unicode codepoint to its official name (example) don't need to be updated frequently unless there is a new Unicode update (Like Unicode 13.0.0 to Unicode 14.0.0). But modules that convert a Unicode codepoint to its image (example) indeed need to be updated frequently depending on the availability of the images on Commons. Ekirahardian (talk) 14:30, 15 April 2022 (UTC)
Thank you for the thoughts. With efficiency I do not mean only the time to cary out a single conversion, but the overall efficiency of the wiki system, including all the stored modules and updates of those. Adding image (P18) to instances of Unicode character (Q29654788) seems to be a good idea, and the modules in single wikis can peek that. Taylor 49 (talk) 14:38, 15 April 2022 (UTC)
I asked elsewhere (on a bot talk page) how we might do this. Unless one of the Wiktionaries wants different images of the characters, I agree it would be best to have them mirror centralized lists, presumably kept on WD. That could be overridden locally if need be, but so far I haven't come across any language-dependent images. Certainly the names should be centralized, since they're standard. And a centralized db should make it easier to extend coverage to additional Wiktionaries.
The one place where I've seen language customization is in the Unicode block names, which are frequently translated. So that at least should allow for local override.
BTW, Taylor's repeated claim of "uploading of thousands of huge modules to hundreds of wiktionaries" is a gross exaggeration. There are 44 modules, some of them quite small. E.g. the images 025 module, to pick one at random, is tiny and has been uploaded to only 11 wiktionaries. Modules 002 and 01F have been uploaded to 29, which is the maximum. So more accurately there are "dozens of modules of varying size uploaded to a few dozen wiktionaries." Manipuri wikt has requested all 44, but I haven't gotten to it yet.
No reason to stop uploading SVG images, though, as all the files will be kept at Commons regardless, and the conversion once decided on will be trivial. Kwamikagami (talk) 17:29, 15 April 2022 (UTC)
Looking at a few entries on Wikidata (https://w.wiki/54BC), there's a couple of entries 844 / 150 000 that have images already in different styles. I wonder if lack of standardization will be an issue? Then again I don't know what the use case for this was supposed to be. This might be fixed by marking the preferred image with preferred rank. Infrastruktur (talk) 19:10, 15 April 2022 (UTC)
Sure uploading of SVG images to commons can and should continue, but maybe not uploading and updating those modules. Local overrride is always inherently possible. No need to permit it here on WikiData. There can be a local table for translating the block names. As to the nonstandard images, I can see several possible solutions:
  • create a new property "Unique image of unicode char" allowing only one image and only in SVG format, complementary to Unicode character name (P9382) (preferred)
  • delete all existing images, and upload the new ones instead, by a bot
  • keep all images, if multiple are present, pick the SVG one, if multiple are SVG, pick just one "first come first served"
Taylor 49 (talk) 19:43, 15 April 2022 (UTC)
Wikidata:Property_proposal/Generic#Unique_image_of_unicode_char Taylor 49 (talk) 20:36, 15 April 2022 (UTC)

Another problem is how one can implement a "reverse query" in LUA: 

SELECT ?officialname ?uniblock
WHERE 
{
 [ wdt:P31 wd:Q29654788 ; wdt:P4213 "6666" ] wdt:P9382 ?officialname ; wdt:P5522 ?uniblock
}

md_docs_topics_lua.html Wikidata:SPARQL_tutorial Taylor 49 (talk) 12:55, 16 April 2022 (UTC)

Still curious what @Ekirahardian: thinks about standardising the image style of character pictures. Sometimes it's more important to understand why a particular rule (such as try to preserve old claims) exists than to always follow it to the letter. I suspect standardising the images would be a nice thing to have, and the tools like Quickstatements don't work all that well with ranks. Also the number of images out of the amount that could be added is miniscule so, deleting the link to the old picture before replacing it with a new one might be pragmatic since this data will be added in bulk, after all we don't want to make things more difficult than they have to be for contributors. If someone complains I'd say that means that they've volunteered to do the job themselves.
@Taylor_49: Not sure what you mean by reverse query, if this is a use case noone has mentioned it yet. When you grab things in LUA the results of that is usually saved in the page cache. However queries are not cached for a long time, so you'd typically use something like Listeria, to have the results cached for some amount of time. But that might not be all that reliable depending on what you intend to use this for. What I've done in the past to improve performance or cut down on the amount of queries is to save the results of the query in Lua or JSON format, this will then act as a fast cache. The downside is this requires help from the site technicians to completely automate, otherwise you'll be running scripts manually from time to time. So yeah, if you actually need efficient reverse lookups then you won't get rid of those pesky modules. Infrastruktur (talk) 13:40, 16 April 2022 (UTC)
@Ekirahardian, Infrastruktur: Well the problem is not page cache, but the fact that I do NOT have the QID. I have a "need Q-item with property YYY having value ZZZ" request. SPARQL can, but how to access it from LUA? Taylor 49 (talk) 21:59, 22 April 2022 (UTC)
This is the XY problem. You say you want something done a certain way, but you're not saying what you are trying to accomplish in plain english. Ekirahardian doesn't say anything about what he's going to use this for either, or whether it's considered useful to the site it was added to. I see no point in continuing this conversation until that happens. No one here reads minds. Infrastruktur (talk) 23:09, 22 April 2022 (UTC)
NOT really. YES we CAN @Germartin1, Infrastruktur: How do I find the Q-item with Unicode code point (P4213) having value "6666" from LUA ? Taylor 49 (talk) 11:52, 23 April 2022 (UTC)

Donation of Bibliographic Info from a Journal

Hi all, My team and I are interested in making bibliographic data from the Semantic Web Journal available in Wikidata.

This would include the following metadata from the papers: title, DOI, DOI URL, authors, author affiliation, issue the article appears in, issue editor list, publication date, preprint date, page start, page end, keywords, and link to the full text of the article where avaialable. (The journal recently moved to full open-access.)

We are happy to maintain the data, and in fact one of our goals is to fully automate this process as much as possible. From a community standpoint, what are the next steps in this process?


Thank you, AndrewEells (talk) 17:11, 18 April 2022 (UTC)

@AndrewEells: thanks for your offer, but nobody seems to have considered it interesting enough to respond. How does your data improve Wikidata? Wikidata has become the dumping ground for scientific papers, this just seems to just add on to the pile. Multichill (talk) 11:10, 23 April 2022 (UTC)

taxon common name (P1843)

taxon common name (P1843) is currently very vague and imprecise, just giving lists devoid of any contextual information other than a language and an optional source reference. Names for animals and plants are frequently highly emotive issues, and the system here needs refinement to accomodate this. Names also vary considerably in whether they are in extensive widespread use, or are only very rarely used; no distinction is currently possible. Some ideas for progress:

  • names derived from demonyms or ethnic slurs considered offensive to some or many people (e.g. n*gger, k*ffir, m*ngol, g*psy, sc*tch, squ*w, p*ki, etc.) need a statement to be used as a reason for deprecated rank (P2241).
  • names commemorating persons not, or no longer, considered worthy of commemoration (e.g. slave holders; see Thick-billed Longspur) also need a statement to be used as a reason for deprecated rank (P2241).
  • names with official status (particularly in the native region of a taxon) need an option for setting as a reason for preferred rank (P7452).
  • names in the USA frequently differ from those in the rest of the English-speaking world (not just '-colored' rather than '-coloured', but also numerous others). It would be helpful if these (notably names sourced from USDA PLANTS ID (P1772)) could be entered as language code en-us rather than en, to indicate they are American usage that may not be used elsewhere. This will need a bot task to convert entries already added.
  • rarely used names (particularly archaic names, e.g. sourced from copyright-expired texts) need some form of tagging to indicate they are no longer in widespread use; some sort of "semi-deprecation" (not necessarily pink background, but will not be picked up by e.g. the VN lists at Commons).
  • factually inaccurate or misleading names also need a similar option for tagging, so that those who wish to strive for accuracy can know those names are not accurate.

MPF (talk) 11:41, 7 April 2022 (UTC)

I agree about inaccurate names. There should be a general-purpose "incorrect name" property, not limited to taxons. Though modelling the explanations for why is something incorrect might be challenging.
And I need to ask: by "m*ngol", do you mean "Mongol"? I don't see how that's offensive. It's an endonym. --Tengwar (talk) 20:21, 23 April 2022 (UTC)

I think that there could be utility in defining some qualifiers that indicate if, in a given source, one common name is preferred over another. For example, the Database of Vascular Plants of Canada (Q19544711) lists accepted names in English and French along with other synonyms in English and French (for an example, see http://data.canadensys.net/vascan/taxon/7174).

I think using language codes for specific varieties of a language will be fraught with problems. Just because a name is found in an American reference source does not necessarily mean that the usage is restricted to the U.S. For English, there are only Wikimedia codes en-ca, en-gb, and en-us. What about Australian English, New Zealand English, South African English, Singaporean English, etc.? We would need codes for all countries where English is spoken. French only has a specific code for Canadian French and Louisiana French, but not Swiss French, Belgian French, Guinean French, Senegalese French, etc. I think labeling something with a code such as en-ca should only be acceptable if the source specifically states that it is providing a specific language variety of the information (for example, terms found in Dictionary of American Slang (Q48813215) can assuredly be labeled as American English). The U.S. is not the only place in the world that uses "color" vs. "colour." According to this article, "around the world, the American way of spelling is now far more popular."

I also disagree with some of MPF's assumptions about certain words being pejorative, particularly the word "Scotch." The Oxford Lexico website says about this word: "The use of Scotch to mean ‘of or relating to Scotland or its people’ is disliked by many Scottish people and is now uncommon in modern English. It survives in a number of fixed expressions, such as Scotch broth and Scotch whisky. For more details, see Scottish." Under "Scottish" it says "The word Scotch, meaning either ‘of or relating to Scotland’ or ‘a person/the people from Scotland,’ was widely used in the past by Scottish writers such as Robert Burns and Sir Walter Scott. In the 20th century, it became less common. It is disliked by many Scottish people (as being an ‘English’ invention) and is now regarded as old-fashioned in most contexts." There's nothing that says the word is pejorative, just disliked by many Scots. The Collins English Dictionary does indicate that "Scotch" is American English and that its use as an adjective is "sometimes offensive." But its use for a plant name just doesn't seem to me to possibly be offensive. It's not putting down Scottish people. Collins notes "The natives of Scotland refer to themselves as Scots or, in the singular, Scot, Scotsman, or Scotswoman. The related adjectives are Scottish or, less commonly, Scots. Scotch as a noun or adjective is objected to except when used of whisky and in established phrases like Scotch egg and Scotch pine. In the United States, Scotch is often used where the Scots themselves, or some Americans of Scottish descent, would prefer Scottish or Scots." I would suggest that "Scotch elm", like "Scotch egg" and "Scotch pine," falls under the category of established phrases that are not objectionable. UWashPrincipalCataloger (talk) 01:09, 11 April 2022 (UTC)

MPF's suggestion that name statements should be marked as deprecated because of actual/supposed/conceivable offence is to propose a misuse of deprecation. Deprecation is for statements that were never true. WD does not deprecate data based on "highly emotional" reactions. --Tagishsimon (talk) 01:44, 11 April 2022 (UTC)
@UWashPrincipalCataloger, Tagishsimon: thanks for your replies. I would certainly support creation of en-au, en-in, en-nz, en-sg, en-za, etc. language codes; I find it strange that they have not been long ago.
Of usage of 'Scot*h', I suggest you visit Scotland and ask people there, how they feel about Americans telling them they must accept American renaming of their native plants for them (and that goes for any other European species where the US naming authorities like USDA and ITIS have changed the native name to something different): it is regarded as [cultural] imperialism, and greatly detested as an insult to their intelligence, the treatment of native rights with contempt. The term may not be pejorative, but it most certainly causes offence when it is suggested (as wikidata sadly now does) to be correct usage. This is a fact, and needs to be recorded in wikidata, for the data to be accurate. If deprecation is not appropriate, then some other form of notation is needed, to indicate that what may be acceptable in some areas, is not in others. Consider for example a German author writing an article in English about Ulmus glabra for a scientific paper, and wanting to mention the English name: how will he know that Wych Elm is the correct name to use, and that 'Scot*h elm' is considered offensive by many, if wikidata provides no clues when he turns to it? This sort of information is very important, and needs to be recorded.
Of the Daily Mail article cited above, a reminder that en:wp banned use of the Daily Mail several years ago as being an unreliable source. This article fits exactly into the sort of "sensationalism and flat-out fabrication" that they were banned for. I certainly would not rate their claim above as trustworthy. - MPF (talk) 15:15, 11 April 2022 (UTC)

I think several of the reasons suggested for deprecation (or it's opposite) are a matter of opinion, not fact, and that can sometimes be inferred from the source itself.

Notes inserted below each point; @Plantdrew, UWashPrincipalCataloger: - MPF (talk) 22:30, 21 April 2022 (UTC)
  • Whether a name is archaic is an opinion (when is the cutoff? an arbitrary date is an opinion), and archaicness can be inferred if the source for a common name was published long ago.
  • It may be visible on wikidata if the source is cited with a publication date long ago, but it is not visible (a) if the source is secondary, and more importantly, (b) in details exported from wikidata to other wiki projects - MPF (talk) 22:30, 21 April 2022 (UTC)
  • That McCown's longspur is deprecated can be inferred from it only being sourced to older versions of IOC, not the most recent (and there is a movement to rename all birds with eponyms, regardless of whether the namesake is worth of commemoration; if that succeeds do we really need to flag some eponymous names as having an unworthy (opinion again) namesake?
  • From which, I conclude that it is reasonable to tag names generally as deprecated, if they are only used in an older version of a source? - MPF (talk) 22:30, 21 April 2022 (UTC)
  • "Official" status? Who decides that? A government or language academy? A international learned society? A regional learned society? What if a government and international learned society disagree on an "official" common name; will multiple names be flagged as "official"? Picking just one is an opinion. If somebody knows that certain governments or learned societies are in the habit of designating "offical" common names, that can be inferred by having that entity as a source for the common name (admittedly, many people don't know which entities are in the habit of designating "official" common names)
  • It 'just is'; disagreement like you clearly want, just doesn't happen. You're quibbling to try to discredit the near-universal UK concept of one English name being correct, and others incorrect. It's how we do things here. Much the same as formal scientific names, one correct, others invalid synonyms. Many/most other countries in Europe are the same; see e.g. the French wiki page nom normalisé; read it, understand it, and stop trying to apply American concepts of naming ("every vernacular name is of equal status, regardless of its source") to everyone. Wikidata is international, and not the sole preserve of US ideas and concepts. To exclude UK concepts of naming, is contrary to the wiki community ideals of inclusiveness; I, like at least some other UK editors I know, have felt very unwelcome at times on wiki projects for not wishing to submit to US supremacy in ideas and concepts. That should not be happening. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • I will qualify the above, by adding that not everyone in UK holds with these ideas; some prefer the US styles. But equally, the converse is also true, many in US (e.g. American Ornithological Society (Q465985)) adhere to more European concepts of right and wrong in vernacular names. Ditto, CNN (Q48340), in their famous 'Facts First' tweet pointing out that correct naming matters. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • Even in America, you must surely accept that not all vernacular names are of equal validity or status; the policy at en:wp of treating them so is ludicrous. For one example, see white spruce, listing it as "a common name for several species of spruce" without any qualification at all, despite it being the de facto universal standard name for Picea glauca, and virtually never used for either of the other two (likely only as misidentifications). Wikidata should not follow this sort of nonsense; we very badly need some form of distinguishing between widespread, and very minor, uses of names. Without it, lists of names used become worthless, as they become without meaning if the same name is given to multiple taxa. It needs some way of tagging rarely-used names as 'low importance', so that while they can still be found by wikidata's search, they are not automatically exported to other wikimedia projects where they are likely to cause confusion. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • Factually inaccurate? Again, a matter of opinion in deciding what a name accurately refers to in the first place. Is it inaccurate to use the name "lily" for plants formerly, but not currently classified in the family Liliaceae (or should "lily" be restricted only to members of the genus Lilium, let alone any other former/current members of the Liliaceae). The "official" name for plants in the genus Phormium, according to MPF's favorite source, the BSBI, is "New Zealand flax". Phormium isn't at all closely related to "true flax". MPF, get the BSBI to change that before you start complaining about: "Wollemi pine", "prairie dog", "jellyfish", or "water lily" (none of the people that common names are supposed to serve have any clue why the last is sometimes written as "water-lily"; pedants sticking hyphens into common names is not actually helpful). Plantdrew (talk) 05:07, 15 April 2022 (UTC)
  • Granted that BSBI are not perfect in all of their choices, but overall, their list is widely (close to universally) accepted in UK, and should be followed at least for English names of European native species. Since Phormium is not a European species anyway, BSBI's name is of low relevance; better to follow New Zealand usage, where (as with other NZ endemic plants), the strong trend is to adopt native Maori names into English (in the case of Phormium, 'Harakeke') to remove the misleading names imported by settlers. As for your remark "pedants sticking hyphens into common names is not actually helpful" - that is your opinion, which I find demeaning and offensive, and many (including leading US authorities like American Ornithological Society (Q465985), United States Forest Service (Q1891156), and others) would disagree very strongly with. Sorry, but your turn for not being helpful. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • If we have a discussion about whether to record important information, we should look at the sources you could cite for that important information. Having discussions about who's worthy of commemoration within Wikidata should be avoided as much as possible.
To the extend that there is one English name that's better than others, "best rank" is the way we would label that name and not deprecation. ChristianKl
@ChristianKl: - that is certainly a good idea, but as mentioned above, we also need the means to 'half-hide' names that are worse than others. Otherwise, exports from wikidata to other wikimedia projects become excessively cumbersome and increasingly worthless with huge long lists of very rarely used vernacular names that only serve to confuse and mislead users. - MPF (talk) 22:30, 21 April 2022 (UTC)
@MPF: I don't consider names to be worthless, even if they are not in widespread use anymore. Such names were in use at some point. When I find some weird name in an older book (or new book using stylized language), it's useful to be able to find the e.g. plant by that older name. I do see some value in marking names as outdated or offensive, but I wouldn't "half-hide" them. Other projects can either not import/process outdated/offensive names at all or import them with the "outdated" or "offensive" qualifiers.
But of course "outdated" is an opinion. It might even be outdated in one region, but not in another region. "Offensive" can be even more of an opinion, depending on the name. Is "wild ass" offensive? Offensiveness can also increase or decrease over time as words shift meanings. There will be arguments and edit wars about all that. It might be better to try to derive some of it programmatically. For example if a name was marked as named after (P138) instance of (P31) human (Q5) and the human in question is marked as someone you consider evil (e.g. slave owner, Confederate soldier, Z (Q111103866) supporter), you can consider the name to be offensive. Same if the name contains a word that you consider offensive.
And I see that you marked "McCown's Longspur" as deprecated. I don't think deprecation is the correct way of modelling offensiveness. Instead, I marked the name as has characteristic (P1552) offensive (Q76500861). --Tengwar (talk) 19:51, 23 April 2022 (UTC)
I'm also doubtful about whether this is the best place for the discussion. Wikiproject Taxonomy would likely be better. ❪✉❫ 10:58, 15 April 2022 (UTC)
I've no objection to its being moved there, if that is generally felt to be the best place - MPF (talk) 22:30, 21 April 2022 (UTC)

Can checksum (P4092) be used for software?

Can checksum (P4092) be used for software? Checksums that is. If not, I'm willing to host such data on an own Wikibase instance. Thank you. Maskingself (talk) 07:51, 19 April 2022 (UTC). I changed my mind, if nobody wants the data I will host the Wikibase intance locally but publish the RDF(linked data) on the web in a "recurring fashion". That way, more linked data for the internet in matters I'm concerned. I might publish to Internet Archive, if nobody wants this data here Maskingself (talk) 08:09, 19 April 2022 (UTC)

If the software is notable you can add a checksum for the latest stable release. However I think adding checksums for all the releases is junk data, so this should be hosted elsewhere. You don't really need a Wikibase instance for something like this, most FOSS projects simply store the checksum in a file on the webserver, with the filename of the original file with a suffix of ".sha1" or whatever hash you prefer, this is dead easy to generate with a script. Infrastruktur (talk) 16:04, 19 April 2022 (UTC)
I'll have to quit Wikidata and work on Wikiversity to work on education materials. Wikidata is severely lacking. Maskingself (talk) 09:15, 24 April 2022 (UTC)
Though I thank you for your answer. It inspired me to help people to create more linked open data (Q18692990) Maskingself (talk) 09:19, 24 April 2022 (UTC)

Bus stops

Considering adding a bunch of bus stops for a city with coordinates, from a source that is available under an open license. The examples I've looked at doesn't connect one stop to another, so I was wondering how these are modelled on Wikidata, is a pair of bus stops, each going the opposite direction of the other considered one bus stop, or should I add one bus stop for each direction? Also are bus stops considered notable without sitelinks? And third is there a property like adjacent station (P197) that can be used for bus stops? I wasn't able to find one. If this doesn't exist, should it be added? Infrastruktur (talk) 21:35, 20 April 2022 (UTC)

  1. Depends on how much it buggers up coordinates to use only one item. Train stations with multiple directions of railway line tend to be modelled in single items. Bus stops in my experience - (e.g. transmodel eurobus as NT stop space) - tend to be modelled as discrete records.
  2. IMO yes, they're notable per WD:N criteria 2 and, arguably, criteria 3.
  3. Use adjacent station (P197), which has the useful alias 'next stop'. --Tagishsimon (talk) 21:52, 20 April 2022 (UTC)
We could extend the definition of P197 to include all transport routes (train, bus, tram, ferry, etc.). However, there is the problem that it would be nice if we could also indicate the direction of traffic. Where I live, there are both bus routes where the buses go both ways, and bus routes where they only go in one direction. For the latter case, you would need separate properties for "previous station" and "next station" or equivalent qualifiers. If the bus stops for each direction are in different places (e.g. on opposite sides of the road) it would be most accurate to have items for each direction, but it also happens that buses in both directions stop at the same place. --Dipsacus fullonum (talk) 22:00, 20 April 2022 (UTC)
Do I use the connecting line (P81) qualifier for adjacent station (P197) to denote which "line" or rather route number the statement applies to? It could be very tricky adding the routing, so I guess I'll start with just the stops, pun intended. Edit: I guess I could use the the towards (P5051) qualifier to specify direction, I saw it used on some french metrobus service. Infrastruktur (talk) 18:58, 21 April 2022 (UTC)
I understand P5051 as indicating the direction to a particular terminus, not whether the trains (or buses) are heading to the neighbouring station or coming from it or both. Trains usually always run in both directions (if there are exceptions, I don't know them), while buses (where I live) often only run a route in one direction. --Dipsacus fullonum (talk) 03:40, 22 April 2022 (UTC)
PS. There is also the problem that bus routes are unstable and often change as it is easy to change a bus route and move stops (compared to moving a railway). --Dipsacus fullonum (talk) 03:48, 22 April 2022 (UTC)
I would rather use connecting service (P1192) to model the "transport line" (be it tramway/service/train/bus etc). Sometimes P1192 is better for metro lines (it happens there are single physical train track that are serviced by diffent "metro passenger lines") Bouzinac 💬●✒️●💛 12:08, 22 April 2022 (UTC)
Do we really want to have all bus stops on Wikidata? Sounds more like something for OpenStreetMap. They also have a good system to connect stops and lines. Multichill (talk) 11:06, 23 April 2022 (UTC)
Good idea. I see for the city I was thinking of working on, the "relations" on OSM is just connected to one single operator Q-item on Wikidata. Example: https://www.openstreetmap.org/relation/9965416 . If I could instead change this to link each "relation" to a Q-item for a bus route on Wikidata, that would probably be the goldilocks level of detail. Just one question: Can I edit the Q-number from the browser on the OSM website?
I'm reconsidering adding routing for busses. As D.F. pointed out they tend to change, leading to data that is not maintained, so yes this probably a bad idea. As for adding just the stops, that's a part of more permanent infrastructure, and having the ability to query against bus stop coordinates along with a P10675 (P10675) connection is conceivably useful, so I still think this is worth adding to Wikidata. Infrastruktur (talk) 16:43, 23 April 2022 (UTC)
Wow. They support SPARQL and it can be federated from Wikidata. They got coordinates and the NSR IDs for all the stopplaces available. ex.1 This definitely changes things big time. I've just started to scrape the surface at the moment, but this basically means there's no point in adding either stops or routing to WD. I believe the linking to Wikidata will be better if there is Q-items for the routes (as a whole) though, so that's the current plan. Infrastruktur (talk) 00:03, 24 April 2022 (UTC)
Linking bus routes from OSM to Wikidata would be a nice little project. I picked London Buses route 281 (Q16987409) at random and found it didn't mention the OSM entity https://www.openstreetmap.org/relation/7945543 which in turn, while it had a wikidata entry, was for the generic London Buses. So plenty of structure both ends, socially useful, and a clear gap to be bridged. https://wiki.openstreetmap.org/wiki/Key:wikidata#Adding_missing_items_to_Wikidata shows now they assign wikidata entries to their elements. Vicarage (talk) 07:03, 24 April 2022 (UTC)
Still an OSM noob, but I guess the "network:wikidata" tag is supposed to be a machine-readable version of the name of the bus network owner. If that's the case I'll be using the plain "wikidata" tag to link up the routes. Infrastruktur (talk) 07:42, 24 April 2022 (UTC)
@Infrastruktur: Yes, that's exactly the difference between the network:wikidata key and the unqualified wikidata key. Both keys can appear on the same relation, along with several other Wikidata-related keys. network:wikidata values are typically added using editor presets collected by the Name Suggestion Index (Q62108705) project (and linked in the other direction using OSM Name Suggestion Index ID (P8253)). If a bus company is missing from NSI, please open an issue there or submit a pull request with the details, including the corresponding QID. Minh Nguyễn 💬 00:43, 25 April 2022 (UTC)
@Infrastruktur: Here are some more examples of what you can do with OSM's SPARQL endpoint. Unfortunately, the service isn't very healthy and is ten months behind on OSM data, but hopefully it's of some use to you. [4][5] Minh Nguyễn 💬 00:47, 25 April 2022 (UTC)
Thanks. I was wondering about that. Infrastruktur (talk) 08:33, 25 April 2022 (UTC)

"or" in dates

I want to add date of birth (P569) like 1886 or 1887 see Q7064185#P569. Does it the correct way to add the info. Also see Q26235795#P569. I wonder if using logical disjunction (Q1651704) with refine date (P4241) would be better (logical) way. Geagea (talk) 08:25, 25 April 2022 (UTC)

Yes I wonder what answer you will get. I was told that if the fact is uncertain, its better not to add it. But I am not happy with that recommendation, bacause if I am editing such item I am probably the last one, who find some information ever and noeone will have a look on it in the future and I would forgot. Juandev (talk) 11:12, 25 April 2022 (UTC)
@Juandev The general rule is to add information with a reputable source, even if the truth is uncertain or the information is plain wrong. You can use ranks for better or worse bits of information. --Emu (talk) 14:40, 25 April 2022 (UTC)
I consider Wikidata to be written to be understood by computers first and foremost and not humans. Computers like consistency, so if there isn't a very good reason to do something differently it's best to stick with the "popular" choice. Infrastruktur (talk) 11:24, 25 April 2022 (UTC)
And to confirm, the popular choice here is as your two examples; the main property value taking a broader time value, qualified with earliest and latest dates. --Tagishsimon (talk) 11:26, 25 April 2022 (UTC)

macedonian/bulgarian ethnicity

In Anastasia Uzunova (Q63343779) some changes (diff) have been made that look suspicious to me, but I couldn't find an external source in a language I'm literate in. Can anyone help out? -- Dr.üsenfieber (talk) 10:23, 25 April 2022 (UTC)

Ethnicity is always the trouble and there are discussion on it. The Wikipedia article does not have citations and Google is not helpful either. Juandev (talk) 11:10, 25 April 2022 (UTC)
If there are no sources for either value, I'm tempted to set it to `unknown value` -- Dr.üsenfieber (talk) 12:44, 25 April 2022 (UTC)
Better still, delete the statement. It shouldn’t be here anyway if there is no source. --Emu (talk) 14:31, 25 April 2022 (UTC)

Wikidata weekly summary #517

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Closed request for adminship:
    • New requests for permissions/Bot:
  • Tool of the week
    • Wikitaxa is a software of taxonomy data written in R.
    • User:So9q/fatcat-link.jsscrip is a userscript for looking up fatcat! DOIs. It adds a link to the fatcat! database in the Tools' section on items.
  • Development
    • Lexicographical data: Worked on showing the name of language variants in the language variant selector and added the new information box to help people get a better understanding of lex. data.
    • REST API: Finished the initial implementation of the endpoint for getting data for a full Item and discussed feedback, testing and roll-out plans.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

How to cite Web of Science

How do I cite Web of Science if I have access via institution and it's in the URL? Let's say I create an item for a scientific article and I would reference some information from the Web of Science.--Juandev (talk) 11:06, 25 April 2022 (UTC)

@Juandev: Ask again in a different way if this answer is not what you wanted.
If you are trying to cite a Web of Science indexed paper for a claim in Wikidata, then do not cite anything about Web of Science at all. Instead, using the reference function in Wikidata items, cite the Wikidata item for a paper which you have already indexed in Wikidata. If you want to connect that paper to Web of Science, use Web of Science ID (work) (P8372) on the item for the paper, not on the item where you are citing the paper. Bluerasberry (talk) 15:18, 25 April 2022 (UTC)

Use of Wikidata to generate categories for media in the Commons category "media needing categories".

There are approximately 1.4 million media in the Commons category "media needing categories". Many of these are used in a Wikipedia article and/or Wikidata. Most Wikipedia articles where such an image is used have a link to Wikidata. In my opinion, it is possible to determine relevant Commons categories from Wikidata. At Commons:Bots/Work requests I made a request. Although I have explained it with examples, there are more practical aspects to mention to ensure that the results are as relevant as possible.
My question is whether it has been put in the right place there or whether it is better to ask it within Wikidata. Wouterhagens (talk) 13:46, 25 April 2022 (UTC)

@Wouterhagens I’m not an expert on Commons, but aren’t their categories considered old technology that should eventually be phased out and replaced by Structured data? If this is true, this might be a lot of work (setting up the bot, fixing details, cleaning up the mess almost every bot is bound to create) for little practical gain … --Emu (talk) 14:27, 25 April 2022 (UTC)
I used to do automatic categorization with User:CategorizationBot (between 2009 and 2015). Don't waste time on trying to patch up the old system, instead focus on the new system. Multichill (talk) 20:09, 25 April 2022 (UTC)

如何记录中国“中科院嫌知网受权费用高而停用知网服务”事件的相关信息

主要包含每个学校与知网每年的授权费用信息。 如何获取可以参考这里.

我已经创建了2个数据 Q111667360,Q111666771.  – The preceding unsigned comment was added by Bangbang.S (talk • contribs).

@Bangbang.S: You might get more response if you ask on Wikidata:Project chat/zh. Bovlb (talk) 19:56, 25 April 2022 (UTC)

New "mul" term language code available on Test Wikidata

(This change is relevant for all Wikidata users working with labels, descriptions, and aliases.)

Based on a long-standing community request we have enabled a new language code for labels, descriptions, and aliases on Test Wikidata: “mul”, a special language code meaning “multiple languages”. It is intended to replace the current duplication of certain labels and aliases in many languages: instead of the given name Douglas (Q463035) having the label “Douglas” in hundreds of Latin-script languages, it should be enough to add it once as the “mul” label and have all other languages falling back to that (before, as usual, falling back to “en” as a last resort). This should reduce the amount of redundant data in Wikidata, and relieve some pressure from the query service. A big thank you goes to all people involved in the discussions!

The purpose of the Test Wikidata version of this feature is to determine whether the current functionality is already sufficient, or whether the feature needs more work before it can be enabled on Wikidata proper.

Current implementation:

  • You can interact with the new language code using the API.
  • The new language code appears in the table of labels at the top of an item page for users whose Babel information includes “mul” (or who use ?uselang=mul in the URL). If there is already a “mul” label, it will be available for everyone under the usual “all entered languages” option.
  • The page heading will fall back to the “mul” label if necessary. Fallbacks to “mul” have the usual “indicator” that shows a fallback took place (CSS class wb-language-fallback-mul).

For more details, see phab:T285156 (or phab:T297393 for the Test Wikidata implementation). You are welcome to leave any feedback about the technical implementation of the new language code on these tickets.

The new language code will very likely need adjustment of Wikidata policies and guidelines. In case you would like to contribute to drafting preliminary new guidelines, a good starting point is: Help talk:Label#Drafting of guidelines for new language code mul.

Cheers, -Mohammed Sadat (WMDE) (talk) 15:48, 25 April 2022 (UTC)

Separate item for podcast?

Critical Role (Q109341430) is a podcast (podcast (Q24634210)) adaptation of Critical Role (Q22079668). This means that IDs like Podcast Addict show ID (P9007) are placed on Q109341430 instead of Q22079668. This means that {{Podcast_platform_links}} returns nothing when placed on Critical Role. Should these two items be merged or is there a reason to keep them separated? –MJL ‐Tauk‐☖ 17:44, 25 April 2022 (UTC)

@MJL: When I asked the editor who split the articles this in November, they cited: Wikidata_talk:WikiProject_Podcasts#Radio_show_vs_podcast. Over on Wikipedia, there was an initial discussion on how to fix the template (since templates are Wiki project specific) but nothing has come of it yet. Sariel Xilo (talk) 23:20, 26 April 2022 (UTC)

Question about formatter URL

The formatter URL for Italian Navy Lighthouses and Beacons ID (P3863) is http://www.marina.difesa.it/cosa-facciamo/per-la-difesa-sicurezza/fari/Pagine/$1.aspx This works in most cases, but for Capo Grosso Lighthouse (Q55140133) the identifier is 3120.3 and the URL excludes the period, i.e.

Is there any way the formatter can be made to work with this? — Martin (MSGJ · talk) 14:14, 26 April 2022 (UTC)

Maybe @ArthurPSmith: would be willing to add such a feature to his nice tool? Infrastruktur (talk) 17:09, 26 April 2022 (UTC)

2022 Board of Trustees Call for Candidates

You can find this message translated into additional languages on Meta-wiki.
More languages • Please help translate to your language

The Board of Trustees seeks candidates for the 2022 Board of Trustees election. Read more on Meta-wiki.

The 2022 Board of Trustees election is here! Please consider submitting your candidacy to serve on the Board of Trustees.

The Wikimedia Foundation Board of Trustees oversees the Wikimedia Foundation's operations. Community-and-affiliate selected trustees and Board-appointed trustees make up the Board of Trustees. Each trustee serves a three year term. The Wikimedia community has the opportunity to vote for community-and-affiliate selected trustees.

The Wikimedia community will vote to fill two seats on the Board in 2022. This is an opportunity to improve the representation, diversity, and expertise of the Board as a team.

Who are potential candidates? Are you a potential candidate? Find out more on the Apply to be a Candidate page.

Thank you for your support,

Movement Strategy and Governance on behalf of the Elections Committee and the Board of Trustees
--YKo (WMF) (talk) 03:02, 27 April 2022 (UTC)

Let's talk about the Desktop Improvements

Hallo!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on 29 April 2022 at 15:00 and 20:00 CEST on Zoom. Click here to join. Meeting ID: 88045453898. Dial by your location.

Agenda

  • Update on the recent developments
  • Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English and Polish, and additionally: Indonesian at the first meeting, and French and Italian at the second meeting. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hopen je te zien! SGrabarczuk (WMF) (overleg) 14:48, 27 April 2022 (UTC)

Subclass has parts

"An entity should not have statements for both has part(s) of the class and subclass of" Why not? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:33, 28 April 2022 (UTC)

So that would be the final constraint on has part(s) of the class (P2670) at Property:P2670#P2302. It seems that a choice was made & documented at Help:Basic membership properties#has part or parts (P527) vs. has part(s) of the class (P2670), which boils down to:
Me, I think that's a wrong call, but what do I know. (I'd go for has part(s) (P527) used for instance-instance, and has part(s) of the class (P2670) for instance-class or class-class.) --Tagishsimon (talk) 13:53, 28 April 2022 (UTC)

Performance prevents the creation of new items

Depending on time of day, I find that I can no longer add publications using the Scholia software. Thanks, GerardM (talk) 13:22, 28 April 2022 (UTC)

Let's talk about the Desktop Improvements

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on 29 April 2022 at 13:00 UTC and 18:00 UTC on Zoom. Click here to join. Meeting ID: 88045453898. Dial by your location.

Agenda

  • Update on the recent developments
  • Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English, French, Italian, and Polish. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hope to see you! SGrabarczuk (WMF) (talk) 00:35, 26 April 2022 (UTC)

The first meeting starts in 40 minutes! We'll be waiting for you. SGrabarczuk (WMF) (talk) 12:25, 29 April 2022 (UTC)

Coming soon: Improvements for templates

Fundamental changes in the template dialog.

Hello, more changes around templates are coming to your wiki soon:

The template dialog in VisualEditor and in the 2017 Wikitext Editor (beta) will be improved fundamentally: This should help users understand better what the template expects, how to navigate the template, and how to add parameters.

In syntax highlighting (CodeMirror extension), you can activate a colorblind-friendly color scheme with a user setting.

Deployment is planned for May 10. This is the last set of improvements from WMDE Technical Wishes' focus area “Templates”.

We would love to hear your feedback on our talk pages!

-- Johanna Strodt (WMDE) 11:14, 29 April 2022 (UTC)

Regiments and Battalions on Wikidata

Hi all, the Argyll and Sutherland Highlanders (Q3135445) Regimental Museum at Stirling Castle are looking to model how military information is added to Wikidata and have become stuck at how to model Regimental Number and Battalion information. Regiment and Battalion might be good properties to create but I’d be surprised if there hadn’t been thoughts/more progress mapping such elements to WIkidata already. e.g. Had a quick look at a famous military figure of George S. Patton (Q186492)on Wikidata to see how a prominent example is modelled.

The property of member of (P463) seems the one used for Patton. This might work for Battalion if we create Wikidata entries to link to each battalion. We can also create Wikidata entries for each regiment. Because if we can create Wikidata items for the battalions and the regiments then we can link to them using P463 member of property.

If member of (P463) is a bit too generic to be useful for military modelling then maybe we go ahead with property proposal for regiment and battalions and kickstart a conversation about how regiment and battalion information ought to be consistently modelled across the project. Let me know if you have any thoughts or advice here here. Stinglehammer (talk) 15:25, 26 April 2022 (UTC)

@Stinglehammer: military unit (P7779) was created a while back, which would seem to be what you're looking for. Value should be the most narrowly identifiable unit the subject was a member of at any time. From this query https://w.wiki/56g$ subject has role (P2868) seems most common way to indicate role within the unit, though position held (P39) and military rank (P410) also available and used.
Here's also a query for the most commonly used properties on military units: https://w.wiki/56gy ; so part of (P361) can be used to establish a hierarchy as to how smaller units fit within bigger units. Jheald (talk) 16:18, 26 April 2022 (UTC)
@Jheald, Stinglehammer: Agree that for person to unit, military unit (P7779) is the best option. There is no easy solution for service numbers, as the proposal for a generic service number property stalled a few years back - it might be worth reopening that.
For linking units, I think this could be tricky - there's a few different broad systems at work here, so a single standard model may not work. (Broadly speaking, the UK uses a "w:Regimental system", where battalions have an organisational parent regiment/corps but a completely different "operational" parent unit; in other countries the concept of a parent regiment may not exist at all). So you have two different sorts of relationship to model in the UK structure:
They're both arguably "part of", but it would probably get confusing to model them with the same sets of properties - and both are things that are valuable to have modelled. I think the "operational" linkage - which is the one every military will have - is the one that makes most sense to model with part of (P361) (with appropriate date qualifiers), and then to model the additional nuance of the regimental/corps link we could have something like parent organization (P749)? Andrew Gray (talk) 22:03, 26 April 2022 (UTC)
@Andrew Gray: Alternatively use some appropriate object has role (P3831) qualifier, so that the battalion still gets picked up by a naive query using part of (P361) (or has part(s) (P527)) either way, whether somebody is trying to drill down the operational structure or the organisational structure? Though it is difficult to chain qualifier tests in a path query. Jheald (talk) 09:28, 27 April 2022 (UTC)
@Jheald: I think that could work, I'm just wondering if trying to lump the two different types of relationship in there might get confusing and difficult to ensure both were maintained/given appropriate qualifiers - given "operational" is the normal way to do this, maybe that could be unqualified and the regimental link the qualified one? In terms of querying I think very broadly speaking for the UK model you'd usually only have two layers of this: battalion part of regiment, regiment part of administrative brigade/division (in this case Highland Brigade (United Kingdom) (1948) (Q104816889) then Scottish Division (Q7437706)), and in almost all cases you would only really want to query the first layer, so chaining qualifiers might not be too hard. If you and @Stinglehammer: would like I can try and mock something up for a couple of examples and we can see how it looks? Andrew Gray (talk) 21:42, 29 April 2022 (UTC)

Author of entry in encyclopedia

I'm looking at Encyclopedia of Group Processes & Intergroup Relations (Q106631134)author (P50)Claudia A Sacramento (Q95962053), a claim that was added automatically by Orcbot. Sacramento is presumably an author of one of the many articles in this edited volume (Q1711593). She wasn't an editor or listed author on the cover. I'm inclined to remove or deprecate the claim. What reason for deprecated rank (P2241) should I use? Alternately, should the claim be kept but qualified somehow? Daask (talk) 13:39, 30 April 2022 (UTC)

@EvaSeidlmayer: Pinging operator of Orcbot in case you have thoughts. Daask (talk) 13:41, 30 April 2022 (UTC)

taxon common name (P1843)

taxon common name (P1843) is currently very vague and imprecise, just giving lists devoid of any contextual information other than a language and an optional source reference. Names for animals and plants are frequently highly emotive issues, and the system here needs refinement to accomodate this. Names also vary considerably in whether they are in extensive widespread use, or are only very rarely used; no distinction is currently possible. Some ideas for progress:

  • names derived from demonyms or ethnic slurs considered offensive to some or many people (e.g. n*gger, k*ffir, m*ngol, g*psy, sc*tch, squ*w, p*ki, etc.) need a statement to be used as a reason for deprecated rank (P2241).
  • names commemorating persons not, or no longer, considered worthy of commemoration (e.g. slave holders; see Thick-billed Longspur) also need a statement to be used as a reason for deprecated rank (P2241).
  • names with official status (particularly in the native region of a taxon) need an option for setting as a reason for preferred rank (P7452).
  • names in the USA frequently differ from those in the rest of the English-speaking world (not just '-colored' rather than '-coloured', but also numerous others). It would be helpful if these (notably names sourced from USDA PLANTS ID (P1772)) could be entered as language code en-us rather than en, to indicate they are American usage that may not be used elsewhere. This will need a bot task to convert entries already added.
  • rarely used names (particularly archaic names, e.g. sourced from copyright-expired texts) need some form of tagging to indicate they are no longer in widespread use; some sort of "semi-deprecation" (not necessarily pink background, but will not be picked up by e.g. the VN lists at Commons).
  • factually inaccurate or misleading names also need a similar option for tagging, so that those who wish to strive for accuracy can know those names are not accurate.

MPF (talk) 11:41, 7 April 2022 (UTC)

I agree about inaccurate names. There should be a general-purpose "incorrect name" property, not limited to taxons. Though modelling the explanations for why is something incorrect might be challenging.
And I need to ask: by "m*ngol", do you mean "Mongol"? I don't see how that's offensive. It's an endonym. --Tengwar (talk) 20:21, 23 April 2022 (UTC)
@Tengwar: sorry, missed this one - because the term was widely used in the past as a pejorative term for people with Down syndrome (Q47715) - MPF (talk) 22:33, 4 May 2022 (UTC)
Oh. TIL. But do you believe some taxons were named after the offensive meaning as opposed to the more widespread meaning? --Tengwar (talk) 00:05, 5 May 2022 (UTC)
@Tengwar: - very unlikely, I'd think; it's just that this particular spelling is toxic for many people. The more usual endonym spelling 'Mongolian' is widely used (as in e.g. Mongolian Lark (Q2522924) or Quercus mongolica (Q1367359)) and is not considered offensive anywhere (as far as I know!) - MPF (talk) 14:29, 5 May 2022 (UTC)
@MPF: I might be mistaken due to my lacking knowledge of English, but isn't "Mongolian something" named after Mongolia and "Mongol something" named after Mongols? I did a quick search and found some uses of the latter, e.g., Mongol epic poetry (Q107473501) or Mongol campaign against the Nizaris (Q92987578). --Tengwar (talk) 20:54, 5 May 2022 (UTC)

I think that there could be utility in defining some qualifiers that indicate if, in a given source, one common name is preferred over another. For example, the Database of Vascular Plants of Canada (Q19544711) lists accepted names in English and French along with other synonyms in English and French (for an example, see http://data.canadensys.net/vascan/taxon/7174).

I think using language codes for specific varieties of a language will be fraught with problems. Just because a name is found in an American reference source does not necessarily mean that the usage is restricted to the U.S. For English, there are only Wikimedia codes en-ca, en-gb, and en-us. What about Australian English, New Zealand English, South African English, Singaporean English, etc.? We would need codes for all countries where English is spoken. French only has a specific code for Canadian French and Louisiana French, but not Swiss French, Belgian French, Guinean French, Senegalese French, etc. I think labeling something with a code such as en-ca should only be acceptable if the source specifically states that it is providing a specific language variety of the information (for example, terms found in Dictionary of American Slang (Q48813215) can assuredly be labeled as American English). The U.S. is not the only place in the world that uses "color" vs. "colour." According to this article, "around the world, the American way of spelling is now far more popular."

I also disagree with some of MPF's assumptions about certain words being pejorative, particularly the word "Scotch." The Oxford Lexico website says about this word: "The use of Scotch to mean ‘of or relating to Scotland or its people’ is disliked by many Scottish people and is now uncommon in modern English. It survives in a number of fixed expressions, such as Scotch broth and Scotch whisky. For more details, see Scottish." Under "Scottish" it says "The word Scotch, meaning either ‘of or relating to Scotland’ or ‘a person/the people from Scotland,’ was widely used in the past by Scottish writers such as Robert Burns and Sir Walter Scott. In the 20th century, it became less common. It is disliked by many Scottish people (as being an ‘English’ invention) and is now regarded as old-fashioned in most contexts." There's nothing that says the word is pejorative, just disliked by many Scots. The Collins English Dictionary does indicate that "Scotch" is American English and that its use as an adjective is "sometimes offensive." But its use for a plant name just doesn't seem to me to possibly be offensive. It's not putting down Scottish people. Collins notes "The natives of Scotland refer to themselves as Scots or, in the singular, Scot, Scotsman, or Scotswoman. The related adjectives are Scottish or, less commonly, Scots. Scotch as a noun or adjective is objected to except when used of whisky and in established phrases like Scotch egg and Scotch pine. In the United States, Scotch is often used where the Scots themselves, or some Americans of Scottish descent, would prefer Scottish or Scots." I would suggest that "Scotch elm", like "Scotch egg" and "Scotch pine," falls under the category of established phrases that are not objectionable. UWashPrincipalCataloger (talk) 01:09, 11 April 2022 (UTC)

MPF's suggestion that name statements should be marked as deprecated because of actual/supposed/conceivable offence is to propose a misuse of deprecation. Deprecation is for statements that were never true. WD does not deprecate data based on "highly emotional" reactions. --Tagishsimon (talk) 01:44, 11 April 2022 (UTC)
@UWashPrincipalCataloger, Tagishsimon: thanks for your replies. I would certainly support creation of en-au, en-in, en-nz, en-sg, en-za, etc. language codes; I find it strange that they have not been long ago.
Of usage of 'Scot*h', I suggest you visit Scotland and ask people there, how they feel about Americans telling them they must accept American renaming of their native plants for them (and that goes for any other European species where the US naming authorities like USDA and ITIS have changed the native name to something different): it is regarded as [cultural] imperialism, and greatly detested as an insult to their intelligence, the treatment of native rights with contempt. The term may not be pejorative, but it most certainly causes offence when it is suggested (as wikidata sadly now does) to be correct usage. This is a fact, and needs to be recorded in wikidata, for the data to be accurate. If deprecation is not appropriate, then some other form of notation is needed, to indicate that what may be acceptable in some areas, is not in others. Consider for example a German author writing an article in English about Ulmus glabra for a scientific paper, and wanting to mention the English name: how will he know that Wych Elm is the correct name to use, and that 'Scot*h elm' is considered offensive by many, if wikidata provides no clues when he turns to it? This sort of information is very important, and needs to be recorded.
Of the Daily Mail article cited above, a reminder that en:wp banned use of the Daily Mail several years ago as being an unreliable source. This article fits exactly into the sort of "sensationalism and flat-out fabrication" that they were banned for. I certainly would not rate their claim above as trustworthy. - MPF (talk) 15:15, 11 April 2022 (UTC)
How many Scottish people have you talked to? Many of my Scottish friends would be happy, for instance to cook with en:Scotch bonnet peppers, or eat a en:Scotch egg, and none of them have ever written "Scot*h" in anything I've read. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 12 June 2022 (UTC)

I think several of the reasons suggested for deprecation (or it's opposite) are a matter of opinion, not fact, and that can sometimes be inferred from the source itself.

Notes inserted below each point; @Plantdrew, UWashPrincipalCataloger: - MPF (talk) 22:30, 21 April 2022 (UTC)
  • Whether a name is archaic is an opinion (when is the cutoff? an arbitrary date is an opinion), and archaicness can be inferred if the source for a common name was published long ago.
  • It may be visible on wikidata if the source is cited with a publication date long ago, but it is not visible (a) if the source is secondary, and more importantly, (b) in details exported from wikidata to other wiki projects - MPF (talk) 22:30, 21 April 2022 (UTC)
  • That McCown's longspur is deprecated can be inferred from it only being sourced to older versions of IOC, not the most recent (and there is a movement to rename all birds with eponyms, regardless of whether the namesake is worth of commemoration; if that succeeds do we really need to flag some eponymous names as having an unworthy (opinion again) namesake?
  • From which, I conclude that it is reasonable to tag names generally as deprecated, if they are only used in an older version of a source? - MPF (talk) 22:30, 21 April 2022 (UTC)
  • "Official" status? Who decides that? A government or language academy? A international learned society? A regional learned society? What if a government and international learned society disagree on an "official" common name; will multiple names be flagged as "official"? Picking just one is an opinion. If somebody knows that certain governments or learned societies are in the habit of designating "offical" common names, that can be inferred by having that entity as a source for the common name (admittedly, many people don't know which entities are in the habit of designating "official" common names)
  • It 'just is'; disagreement like you clearly want, just doesn't happen. You're quibbling to try to discredit the near-universal UK concept of one English name being correct, and others incorrect. It's how we do things here. Much the same as formal scientific names, one correct, others invalid synonyms. Many/most other countries in Europe are the same; see e.g. the French wiki page nom normalisé; read it, understand it, and stop trying to apply American concepts of naming ("every vernacular name is of equal status, regardless of its source") to everyone. Wikidata is international, and not the sole preserve of US ideas and concepts. To exclude UK concepts of naming, is contrary to the wiki community ideals of inclusiveness; I, like at least some other UK editors I know, have felt very unwelcome at times on wiki projects for not wishing to submit to US supremacy in ideas and concepts. That should not be happening. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • I will qualify the above, by adding that not everyone in UK holds with these ideas; some prefer the US styles. But equally, the converse is also true, many in US (e.g. American Ornithological Society (Q465985)) adhere to more European concepts of right and wrong in vernacular names. Ditto, CNN (Q48340), in their famous 'Facts First' tweet pointing out that correct naming matters. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • Even in America, you must surely accept that not all vernacular names are of equal validity or status; the policy at en:wp of treating them so is ludicrous. For one example, see white spruce, listing it as "a common name for several species of spruce" without any qualification at all, despite it being the de facto universal standard name for Picea glauca, and virtually never used for either of the other two (likely only as misidentifications). Wikidata should not follow this sort of nonsense; we very badly need some form of distinguishing between widespread, and very minor, uses of names. Without it, lists of names used become worthless, as they become without meaning if the same name is given to multiple taxa. It needs some way of tagging rarely-used names as 'low importance', so that while they can still be found by wikidata's search, they are not automatically exported to other wikimedia projects where they are likely to cause confusion. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • Factually inaccurate? Again, a matter of opinion in deciding what a name accurately refers to in the first place. Is it inaccurate to use the name "lily" for plants formerly, but not currently classified in the family Liliaceae (or should "lily" be restricted only to members of the genus Lilium, let alone any other former/current members of the Liliaceae). The "official" name for plants in the genus Phormium, according to MPF's favorite source, the BSBI, is "New Zealand flax". Phormium isn't at all closely related to "true flax". MPF, get the BSBI to change that before you start complaining about: "Wollemi pine", "prairie dog", "jellyfish", or "water lily" (none of the people that common names are supposed to serve have any clue why the last is sometimes written as "water-lily"; pedants sticking hyphens into common names is not actually helpful). Plantdrew (talk) 05:07, 15 April 2022 (UTC)
  • Granted that BSBI are not perfect in all of their choices, but overall, their list is widely (close to universally) accepted in UK, and should be followed at least for English names of European native species. Since Phormium is not a European species anyway, BSBI's name is of low relevance; better to follow New Zealand usage, where (as with other NZ endemic plants), the strong trend is to adopt native Maori names into English (in the case of Phormium, 'Harakeke') to remove the misleading names imported by settlers. As for your remark "pedants sticking hyphens into common names is not actually helpful" - that is your opinion, which I find demeaning and offensive, and many (including leading US authorities like American Ornithological Society (Q465985), United States Forest Service (Q1891156), and others) would disagree very strongly with. Sorry, but your turn for not being helpful. - MPF (talk) 22:30, 21 April 2022 (UTC)
  • If we have a discussion about whether to record important information, we should look at the sources you could cite for that important information. Having discussions about who's worthy of commemoration within Wikidata should be avoided as much as possible.
To the extend that there is one English name that's better than others, "best rank" is the way we would label that name and not deprecation. ChristianKl
@ChristianKl: - that is certainly a good idea, but as mentioned above, we also need the means to 'half-hide' names that are worse than others. Otherwise, exports from wikidata to other wikimedia projects become excessively cumbersome and increasingly worthless with huge long lists of very rarely used vernacular names that only serve to confuse and mislead users. - MPF (talk) 22:30, 21 April 2022 (UTC)
@MPF: I don't consider names to be worthless, even if they are not in widespread use anymore. Such names were in use at some point. When I find some weird name in an older book (or new book using stylized language), it's useful to be able to find the e.g. plant by that older name. I do see some value in marking names as outdated or offensive, but I wouldn't "half-hide" them. Other projects can either not import/process outdated/offensive names at all or import them with the "outdated" or "offensive" qualifiers.
@Tengwar: - I agree it would be useful to be able to find a plant by an older name; what's at issue, is some way of indicating to users that it is an older name (or in any other way inappropriate), that is unlikely to be understood, if they used it elsewhere outside of wikidata. How would you suggest doing that? - MPF (talk) 22:30, 4 May 2022 (UTC)
But of course "outdated" is an opinion. It might even be outdated in one region, but not in another region. "Offensive" can be even more of an opinion, depending on the name. Is "wild ass" offensive? Offensiveness can also increase or decrease over time as words shift meanings. There will be arguments and edit wars about all that. It might be better to try to derive some of it programmatically. For example if a name was marked as named after (P138) instance of (P31) human (Q5) and the human in question is marked as someone you consider evil (e.g. slave owner, Confederate soldier, Z (Q111103866) supporter), you can consider the name to be offensive. Same if the name contains a word that you consider offensive.
And I see that you marked "McCown's Longspur" as deprecated. I don't think deprecation is the correct way of modelling offensiveness. Instead, I marked the name as has characteristic (P1552) offensive (Q76500861). --Tengwar (talk) 19:51, 23 April 2022 (UTC)
@Tengwar: thanks; is this the best route to follow with other offensive names? - MPF (talk) 22:30, 4 May 2022 (UTC)
I think yes, until a better solution appears. It's not perfect, but better than deprecation. Marking names in this way should make it possible to find them in the future and mark them in a better way. --Tengwar (talk) 00:09, 5 May 2022 (UTC)
Thanks! What would be the best ways to mark other names, such as archaic, or inaccurate / misleading, vernacular names please? Presumably 'has quality' again, with what qualities? - MPF (talk) 22:24, 10 May 2022 (UTC)
I'm also doubtful about whether this is the best place for the discussion. Wikiproject Taxonomy would likely be better. ❪✉❫ 10:58, 15 April 2022 (UTC)
I've no objection to its being moved there, if that is generally felt to be the best place - MPF (talk) 22:30, 21 April 2022 (UTC)
@Tengwar: I don't think you should add has characteristic (P1552) offensive (Q76500861) without any source. Doing original research about what's offensive and what isn't on Wikidata is a recipe for drama. ChristianKl ❪✉❫ 14:57, 7 May 2022 (UTC)
@ChristianKl Previously that entire statement was marked as deprecated by @MPF. Un-deprecating it and marking as offensive was an improvement. I agree that the current state still needs to be improved. For example, currently a source for the offensiveness cannot be added, as Wikidata does not support adding sources to qualifiers. If you can improve the current state further, please do so. --Tengwar (talk) 19:21, 7 May 2022 (UTC)
@Tengwar: Sources apply to the full statement. You can apply the source to the statement. Without a source I would suggest to simply remove it. If MPF wants to do something with it, that process should start with a source.
Adding ways to model to replace deprecation isn't an improvement because there's a chance that the bad way to model it will be copied by people to other parts of Wikidata. ChristianKl ❪✉❫ 00:36, 11 May 2022 (UTC)
I have to ask for clarification. Do you want to:
  1. temporarily keep this way of modelling offensiveness (but with added source) and devise a better way of modelling it later, or
  2. immediately get rid of this way of modelling offensiveness and devise a better way of modelling it later?
Because the first part of your post suggests the former, but the second part of your post suggests the latter.
@MPF: If you have sources for the offensiveness of "McCown's Longspur" name of Thick-billed Longspur (Q263740), please add them to the statement about that name. --Tengwar (talk) 21:32, 12 May 2022 (UTC)
@Tengwar: - reference here. I'm not sure how best to add it to the statement. - MPF (talk) 22:32, 12 May 2022 (UTC)
@MPF, @ChristianKl: Source added. Please improve if needed. --Tengwar (talk) 13:54, 14 May 2022 (UTC)
@Tengwar: Thanks! Any suggestions for suitable tagging for other rarely-used 'uncommon' names? The whole system here remains a mess with so many names added as "common" names which are not in common use at all, but included because they have been used once, somewhere, maybe a long time ago, in a citeable source. The result is, wikidata users can't know easily which name is the right one to use. MPF (talk) 09:06, 20 May 2022 (UTC)
If there is one common name that is better than the others, perhaps its rank should be set to preferred? (With an appropriate reason for preferred rank (P7452) value to make it clear what makes it the preferred name.) --Tengwar (talk) 14:56, 22 May 2022 (UTC)
@Tengwar: Thanks! For someone who struggles with wikidata's complex formulations, how do I record that appropriate reason for preferred rank (P7452), please? Out of curiosity, why should 'Deprecated' not be used (as stated above!), if 'Preferred' can be used? I had assumed the two were counterpoise to each other (they list each other as complementary property (P8882)!); if a particular name can be set as 'Preferred' for reason of being a good name (e.g. standard use), then why can't a name be set as 'Deprecated' for reason of being a bad name (e.g. offensive, or misapplied)? - MPF (talk) 11:46, 25 May 2022 (UTC)
AFAIK preferred means "best value" (most recent, most accurate, HTTPS link as opposed to a HTTP link, etc.), while deprecated means "not true". There's no "true but discouraged" rank other than not being preferred while some other value is preferred.
Just add reason for preferred rank (P7452) as a qualifier to a preferred statement with an appropriate reason. list of Wikidata reasons for preferred rank (Q76637123) has some reasons for preferred rank, but I'm not sure if the list is exhaustive. --Tengwar (talk) 18:56, 25 May 2022 (UTC)
@Tengwar: Many thanks! Although this disparity in application sounds odd, I'll try to follow it. But we really do need (and badly) a "true but discouraged" rank, to deal with a variety of 'bad' names (most importantly offensive ones, but also names liable to cause confusion for any definable reason, such as a name misapplied to a second species when it is usually used for a different species, or geographically or taxonomically misleading names, or archaic names no longer widely used). Any chance this could be instituted? - MPF (talk) 21:58, 25 May 2022 (UTC)
Well, you could propose such a new rank, but I have no idea what is the best place to propose it. Perhaps Wikibase's issue tracker? --Tengwar (talk) 21:31, 26 May 2022 (UTC)
@Tengwar: - Thanks! No idea how to do that, though :'( Any ideas how to go about it? As mentioned above, I find wikidata processes impenetrable - MPF (talk) 21:44, 1 June 2022 (UTC)
I also have no idea about Wikidata processes and structures. I can't help you there, sorry. I guess the only way is to read help pages and google stuff.
All that I know is that Wikibase is the software Wikidata runs. (Just like MediaWiki is the software Wikipedia runs.) And since Wikibase is open-source, it should have an issue tracker (aka bugtracker). Where is it located? How to file an issue there? I have no idea. --Tengwar (talk) 16:55, 2 June 2022 (UTC)
Thanks! Can anyone else suggest, please? - MPF (talk) 22:06, 8 June 2022 (UTC)
There's a ticket I created a while ago asking for a new rank - phab:T210961. You could add your usecase there. - Nikki (talk) 20:56, 9 June 2022 (UTC)
@Nikki: Thanks! I'll take a look there. Not sure what a 'usecase' is, but I'll add a comment - MPF (talk) 06:16, 19 June 2022 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2022/04&oldid=1667484067"